quarta-feira, 12 de outubro de 2011

Primeiro Post - Web-Services sem atrapalhar a performance

Olá a todos!
Sou analista de sistemas da Móveis Simonetti, e aqui temos um infinito de desafios todos os dias.
Um dos desafios que sempre me incomodou era a perca de performance quando o Web-Service de um parceiro parava. O motivo da parada não importa. Sempre que parava, mesmo com verificadores de "ele está lá" ou o que fosse, nossa performance caía.
Pois bem, a solução que propûs não é a solução definitiva para todos os casos, mas atende em vários de nossos casos.

Vamos então ao problema e à solução. E aos pontos positivos e negativos de nossa solução.

Problema: Nosso ssistema se comunica perfeitamente com o do nosso parceiro. On-line! Tudo certo! Até que nosso parceiro tem sua máquina desligada, ou a rede cai. Enfim, algo dá errado.
Quem tentou abrir uma página em seu navegador, que simplesmente não estava lá, sabe o quando isso é demorado.

Solução: Não depender do tempo de resposta do Web-Service para garantir o sucesso de seu processo. Como? Com um controle de requisições, de execução de requisições, e de retorno das requisições.

Nossa solução se baseia no fato de que, a informação não precisa estar lá agora. Ela pode aguardar alguns segundos. Se baseia ainda no fato de que existe um painel de acompanhamento das requisições. Não deixando assim gerar Filas de execução não tratadas.

Detalhando: Imagine que temos que enviar informações acerca de um produto, com descrição do produto, quantidade em estoque, alíquotas e tudo mais para um sistema parceiro (por exemplo uma plataforma de e-commerce). Nós geramos os dados da chamada ao Web-service em um método específico e especializado. Esse método gera então os parãmetros de uma requisição.

O que nos interessa em um Web-Service padrão Soap? Nos interessa o servidor(url), o serviço que vamos chamar (método) e os parâmetros necessários ao serviço, correto? O que teremos de resposta? Outros parâmetros de saída. Então podemos por exemplo guardar o array de parametros de saída e de retorno em uma string gerada por um Json decoder por exemplo.

Pronto, não interessa mais naquele momento à nossa aplicação, se aquele envio foi bem sucedido! Quando a requisição é executada, aquela requisição tem sua situação alterada de 'pendente" para "executada" ou "erro". Daí temos dois controles: 1) resposta a quem de origem criou a requisição. 2) Flag que poderá ser usado ao painel de suporte ao funcionamento do sistema.

Pró da solução: Mesmo que o sistema remoto esteja fora de alcance ou retornando erro, nosso sistema não enfrenta situações de gargalo. Pois quem lida com o gargalo é um script que está livre de condições de corrida, sem controles transacionais ou o que seja. Não bloqueando então nossos registros mais valiosos.

Contra: Dependendo do tempo entre as execuções do script CRON que liga com as requisições, o tempo de espera até que a requisição seja efetuada corretamente pode ser alto.

Caso o tempo seja pequeno (segundos), será necessário ter um controle para que o script não seja executado em duas threads diferentes do apache ao mesmo tempo - falarei sobre essa posssibilidade num próximo post - confesso que acabei de pensar nessa solução :) - se der certo será uma possibilidade para comunicação em tempo QUASE real.

Em resumo, se você precisa se comunicar em tempo REAL com um parceiro, essa solução pode atender. Os web-services de tempo real que podem gerar gargalhos podem ser reduzidos, mas ainda não podem ser extintos do sistema.

Espero que tenham gostado o texto e que enviem críticas.

Abraços!

Um comentário:

  1. Opa, esta é uma interessante solução meu caro Raposo. E tenho certeza que funciona muito bem. Parabéns pela iniciativa do blog. Sucesso!!

    ResponderExcluir