integracao
Share on facebook
Share on twitter
Share on linkedin
Diurno

Integrações Online vs Integrações Offline: qual a melhor estratégia de utilização?

Os sistemas hoje estão cada vez mais complexos e abrangentes. Por isso, é fundamental a adoção de estratégias de gerenciamento para que as tarefas não se tornem difíceis e os sistemas continuem em desenvolvimento. Uma destas estratégias é separar o sistema em outros subsistemas e assim possibilitar que um se integre com o outro de forma simples, gerando um desacoplamento entre eles.

Considerando dois sistemas distintos, A e B, em que um precisa ter acesso a uma informação que o outro já possui, qual a melhor estratégia para acessar essas informações? Criar um serviço que pode ser consumido online no sistema B e o sistema A realiza uma chamada a este serviço ou importar o projeto do sistema B dentro do projeto do sistema A e realizar a chamada de forma offline?

A resposta para esta pergunta é: depende.

– Mas como assim depende? Não existe uma tendência hoje de tudo estar disponível de modo online para que diminua o acoplamento e dependência entre sistemas e a reutilização se torne cada vez mais simples?

A resposta para esta pergunta é sim, porém existem outros fatores que devem ser considerados na hora de definir a arquitetura de seu sistema: tempo de resposta, número de requisições por unidade de tempo, grau de complexidade das operações executadas, quantidade de memória disponível, tecnologia utilizada em cada sistema, entre outros.

O tempo de resposta é o tempo gasto que uma operação demora em retornar alguma informação. O número de requisições por unidade de tempo dimensiona a quantidade de chamadas que irão ser solicitadas ao serviço. O grau de complexidade da operação dá uma idéia do que está sendo realizado no método: pode ser uma operação simples e rápida que não requer muito gasto de memória, como, por exemplo, realizar uma consulta a banco ou pode ser algo mais complexo e demorado que possui um gasto de memória mais alto, como gerar um relatório para o sistema. A quantidade de memória disponível para a aplicação é outro fator que infuencia a escolha. A tecnologia utilizada em cada sistema é mais um item que define, por exemplo, se os sistemas foram construídos utilizando .NET ou não.

Antes de definir qual estratégia utilizar, deve-se avaliar os prós e contras da utilização de cada arquitetura. Ao se realizar a consulta por meio de serviços disponíveis online, mais conhecidos como webservices, as seguintes considerações devem ser pesadas na escolha:

  • Qualquer mudança ou correção será realizada em somente um lugar, tornando um sistema independente de outro;
  • Necessidade de realizar deploy de apenas um sistema caso haja alguma alteração;
  • Simplicidade na utilização, pois é necessário somente referenciar o serviço na aplicação e fornecer os parâmetros que esta espera;
  • Independe da tecnologia utilizada entre cada aplicação;
  • A resposta de uma requisição pode ser mais lenta devido a um alto tráfego na rede ou pelo fatos das duas aplicações estarem em servidores diferentes que ficam distantes um do outro;
  • O serviço pode não responder por alguma indisponibilidade na rede ou outro problema;
  • Limitação de memória ou processamento do servidor para atender à aplicação e também às requisições feitas ao serviço;

Para a estratégia de importar um projeto dentro do outro, realizando assim uma integração offline, devem ser considerados os seguintes itens:

  • Qualquer mudança ou correção deverá ser realizada em mais de um lugar, causando um maior custo de manutenção do sistema;
  • Necessidade de realizar deploy de todos os sistemas que importaram o projeto caso haja alguma alteração dentro dele;
  • A utilização pode ser mais complexa dependendo de como o sistema está construído, não sendo simplesmente realizar a chamada à operação passando os parâmetros necessários;
  • Depende da tecnologia utilizada entre cada aplicação. Para sistemas .NET é possível importar a DLL de um sistema em outro. Para outras tecnologias isto pode não ser possível;
  • Não haverá demora de resposta a uma operação caso haja um alto tráfego na rede, pois tudo estará sendo executado no mesmo lugar;
  • Não haverá preocupação por falta de comunicação entre os sistemas por alguma indisponibilidade, pois ambos estarão sendo processados juntos;
  • Pode aliviar a carga de memória ou processamento do servidor do sistema que foi importado caso haja muita requisição a ele;

Tendo em vista os itens positivos e negativos para cada arquitetura e os fatores que influenciam na utilização de uma ou outra estratégia, deve-se realizar um estudo e verificar qual o melhor a ser usado em cada situação. A seguir seguem dois cenários onde foi avaliada qual a melhor estratégia de arquitetura a ser adotada:

Estudo de caso

Considere um cenário onde existem 03 sistemas: F, P e R.

O Sistema F é um sistema responsável pela geração e impressão de todo o faturamento de uma empresa que possui um altíssimo número de faturas emitidas e impressas diariamente e que está publicada em um servidor compartilhado com outras aplicações (possui memória limitada). O Sistema P é um Portal disponibilizado ao cliente para que este consulte suas faturas e os documentos relacionados a esta. O Sistema R é uma rotina que é executada na madrugada e precisa ser finalizada em poucas horas, e que processa e digitaliza todas as faturas geradas no dia para que sejam disponibilizadas ao cliente.

Considerando este cenário, o Sistema P precisa consultar o Sistema F para obter os documentos da fatura que já passaram por todo o processo de geração, processamento e digitalização. Portanto, o que o Sistema P precisa é obter os documentos digitalizados já salvo em algum lugar e apresentar ao cliente. Analisando com mais cuidado, foi verificado que esta operação ocorre de forma espaçada durante todo o dia, o que não requer um alto consumo do Sistema F.

Já o Sistema R precisa consultar o Sistema F para que este gere toda a documentação relacionada às faturas e depois digitalizá-las em algum lugar. Como o sistema R é executado na madrugada e tem tempo máximo de execução, a performance é um fator importantíssmo. Outro ponto é: como o número de faturas geradas durante um dia é elevado, o consumo do Sistema F durante a execução da rotina é altíssimo, ainda mais que umas das operações é a geração de documentação, processo lento e que exige alto consumo de memória.

Portanto, considerando o Sistema P e R, pode-se avaliar o seguinte: o sistema P não tem uma demanda de processamento alto ao consumir o Sistema F e o número de requisições não é elevado por intervalo de tempo, de modo que a performance não é tão impactante assim. Por isso foi realizada a estratégia do sistema P consumir o Sistema F através de webservices. Já para o Sistema R, como este requer um elevado consumo do Sistema F e possui uma forte demanda por performance, foi adotada a arquitetura de importar o projeto do Sistema F para dentro do projeto do Sistema R, realizando assim uma integração offline das informações.

Conclusão

Mesmo com a tendência de independência entre sistemas e realização de comunicação entre eles por meio de integrações online, existem casos em que é melhor (e talvez somente assim se consiga atender os requisitos estabelecidos no projeto) que a integração seja realizada de forma offline. Portanto, sempre avalie antes os requisitos não funcionais do projeto para verificar se estes podem ser atendidos com o tipo de arquitetura escolhida.

Por: Rafael Ferreira e Jéssica Saliba