Servidor local varre pendencias no servidor Global e retorna a resposta

10 respostas
theoman35lg

Boa tarde pessoal, me deparei com o seguinte problema:

Tenho um servidor na web que fica escutando as requisições dos clientes, quando recebidas estas ficam pausadas esperando outro servidor em uma rede não acessível acessar este que está na web identificar o que foi requisitado e responder, assim o servidor da web pode retornar.

Alguém já viveu algo parecido? Dicas?

10 Respostas

lvbarbosa
  1. O cliente manda uma requisição para o servidor A, disponível na internet. A requisição fica esperando (o browser do cliente com o negocinho girando na aba, como se estivesse carregando algo, aguardando o servidor);

  2. Um servidor B, de tempos em tempos, vai no A e verifica se há requisições esperando e realiza o que tem que ser feito;

  3. O servidor A responde o cliente, finalmente destravando o browser.

É isso?

theoman35lg

Isso, estou procurando alternativas para distribuir esse serviço, serão muitos desses servidores locais, isso foi imposto.

lvbarbosa

Essa ideia de arquitetura me soa bem estranha, talvez porque nunca a tenha visto. Algumas ideias: Porque o servidor A não repassa a requisição para o B, recebe/converte a resposta e manda pro seu cliente?

Você tem duas opções, se quer sincronia:

  1. Efetuar requisições diretamente de A para B e repassar as respostas. A seria mais um “tradutor” ou uma espécie de “man in the middle” do bem

  2. Fazer com que B fique dando pooling em A o tempo inteiro para saber se há requisições para atender

Se você pode trabalhar de forma assíncrona, pode fazer assim também: Quando A recebe uma requisição, manda uma mensagem para uma fila de processamento (que seria B) e retorna imediatamente ao cliente, falando que a requisição foi aceita e vai ser processada em breve. B vai processando o que vai chegando e notifica A que o processamento acabou. A pode mandar uma notificação para o cliente, se for necessário, avisando que sua requisição foi completada.

Não tenho nem ideia de como implementar a parte de pooling, acho que é uma pessima alternativa, porque cada requisição pros métodos do teu servidor web chega em uma thread diferente. A notificação de B para A vai chegar como outra requisição, em outra thread diferente da thread original do cliente. Como é que a gente faz para juntar essas duas?

É isso que me vem em mente, talvez outras pessoas tenham outras ideias mais interessantes!

theoman35lg

É parecido com aqueles bots do telegram, só que pra relatório e em uma aplicação própria… viram o telegram e falaram dá pra fazer… só que o telegram é o telegram. E esse banco em questão é um banco de supermercado então já viu.

theoman35lg

Alguém conhece uma maneira de quando eu conectar no servidor principal conseguir uma conexão direta com o servidor interno mesmo estando ele atras de um modem?

lvbarbosa

Acredito que os bots do telegram são implementados de outra forma, com sockets e salas de mensagem.

Quando a gente envia uma mensagem pro chat, a mensagem é enviada, a requisição não fica “aguardando”. Ela está lá no chat.

Existe um processo assíncrono aqui! Provavelmente existe um listener ouvindo as mensagens nas salas que foram abertas com ele. Quando as mensagens vão chegando, o listener vai enfileirando elas para que o bot as processe de forma serial (ou não, mas enfim). Quando o bot termina de processar, ele envia a resposta para aquela sala de onde a mensagem partiu.

Para a resposta ser vista pelo cliente, existem algumas formas diferentes, como:

  1. Notificações: nosso cliente do smartphone recebe uma notificação que há mensagens novas e sincroniza a sala local com a remota, para que nós possamos ler a resposta.

  2. Pooling: de tempos em tempos, nosso cliente do smartphone manda uma requisição para o servidor web, àquela sala de mensagem específica, e vê se tem algo novo.

lvbarbosa

Seguindo a ideia do telegram, você pode fazer algo assim:

  1. O cliente envia uma mensagem pedindo um relatório;
  2. O servidor responde com algo como “espera aí, já vou te responder”;
  3. Quando a requisição é processada, o servidor envia uma notificação ao cliente (email, push, qualquer coisa) avisando que o relatório está pronto;
  4. O cliente vai lá na hora que quiser e faz o que quiser com o relatório.

Obs: Você pode colocar um botão de refresh na interface do usuário que pediu o relatório, para ele se sentir no controle e ficar clicando loucamente pra ver se vai mais rápido.

theoman35lg

Boa ideia, criar encima de emails…

lvbarbosa

Dá uma olhada na parte de JMS do Java EE se por acaso nunca tiver visto! Se não me engano tem um curso de JMS na alura, caso queira fazer um.

theoman35lg

Farei isso, muito obrigado. Obrigado também pelas ideias, Boa tarde.

Criado 6 de fevereiro de 2017
Ultima resposta 7 de fev. de 2017
Respostas 10
Participantes 2