Deste modo, esse artigo é útil para desenvolvedores que trabalham com plataformas e aplicações corporativas em que exista uma necessidade do uso de notificações entre sistemas e, também, para desenvolvedores que tenham interesse em conhecer um pouco mais das novas tecnologias trazidas pelo HTML 5.
Nas aplicações web, e em grande parte das integrações entre sistemas, o protocolo HTTP garante o envio e recebimento de informações através de uma conexão de rede e pela própria Internet.
Criado em 1991, esse protocolo especifica um padrão de comunicação request-response, ou seja, sempre é feita uma requisição para, assim, obter uma resposta. Expondo também a ideia de uma comunicação cliente-servidor, essa tecnologia ganhou bastante espaço no mercado, se tornando padrão global em comunicação de sistemas.
Com implementações em diversas linguagens, o protocolo HTTP ganhou bastante destaque, dentro do Java, no desenvolvimento de Servlets, Web Services e páginas Web, sendo praticamente utilizado por todas as aplicações Java corporativas focadas em plataformas Web.
Porém, a própria forma que o protocolo HTTP é implementado, ou seja, o conceito de request-response, traz algumas limitações para a comunicação da aplicação, principalmente quando queremos ter uma funcionalidade de notificação assíncrona em nossos clientes, ou seja, queremos ser "avisados" de algo sem ter que "perguntar" ao servidor e sem ter que realizar diversas requisições para atingir esse objetivo.
Nesse contexto, iremos discutir nesse artigo as diversas formas de implementar essa funcionalidade, expondo as motivações de cada uma para, ao final de nossa discussão, demonstrarmos como aplicar o conceito de notificações utilizando as novas tecnologias do HTML 5 e o motivo delas serem ideais para esse tipo de funcionalidade.
HTTP e suas limitações
As comunicações via HTTP, conforme mencionamos na introdução, ocorrem sempre através de um processo de duas etapas: uma requisição e uma resposta.
A requisição é sempre feita pelo cliente, ou user-agent, através dos métodos POST, GET, DELETE, PUSH ou READ. Essa requisição é composta basicamente por um cabeçalho, com metadados sobre o método a ser usado e sobre a requisição, e pelo payload, o corpo com o conteúdo da mensagem.
A partir do momento que o browser do cliente realiza o envio da requisição, é estabelecida uma conexão HTTP entre ele e o servidor e a requisição é processada. Terminado esse processamento, é enviada uma resposta ao cliente, contendo no cabeçalho um status do processamento da mensagem, e a conexão HTTP é fechada.
Esse comportamento nos mostra duas grandes limitações. A primeira delas está relacionada a como manter um estado de conversação com o cliente, uma vez que a cada requisição é aberta uma nova conexão.
Esse ponto foi resolvido com a implementação dos cookies, parâmetros de identificação do usuário que trafegam dentro do cabeçalho da mensagem, indicando ao servidor qual o cliente específico de cada requisição. Através dessa técnica, foi possível implementar o conceito de Sessão HTTP, muito utilizado hoje em dia para autenticar e identificar usuários em sites e páginas Web.
A segunda grande limitação está no fato de que, para receber informações do servidor, o cliente tem sempre que realizar uma requisição. Essa natureza síncrona do processo de comunicação HTTP nos leva a uma limitação quando queremos, a partir de um evento que ocorre em nosso servidor, informar todos os nossos clientes sem a necessidade de um estímulo externo.
A solução para essa questão, por sua vez, não foi tão simples como o uso de Cookies de navegação. Diversas técnicas e tecnologias foram propostas, todas com alguns prós e contras para tratar esse requisito, até a chegada do HTML 5 que, finalmente, propôs uma alternativa viável.
Entre as técnicas mencionadas, tanto do HTML 5 como do protocolo HTTP tradicional, iremos abordar o chamado Poll periódico, Long-Polling, ServerEvent e, finalmente, a tecnologia Web Sockets, para realizar o Push das informações, mostrando as principais diferenças entre essas quatro abordagens e como implementá-las utilizando a linguagem Java.
Poll Periódico
A primeira das técnicas que iremos abordar nesse artigo será o denominado Poll periódico ou, simplesmente, Poll.
Talvez a estratégia mais simplificada de implementação para conseguirmos uma funcionalidade capaz de enviar e receber notificações em nossa aplicação, ou seja, o envio de atualizações do servidor ao cliente, o Poll parte da premissa de que o módulo que deseja ser notificado, no nosso caso o browser do cliente, deve "perguntar" ao servidor a cada período de tempo se existe alguma atualização.
Essa consulta periódica ao servidor, por sua vez, é simplesmente uma requisição HTTP (GET ou POST) que pode ou não ser respondida com dados, dependendo se existem ou não notificações a serem enviadas. Na Figura 1, mostramos um exemplo do comportamento dessa implementação, onde podemos ver as requisições HTTP sendo feitas por AJAX/JavaScript pelo Browser em um loop periódico e o servidor, por sua vez, respondendo as mesmas com as notificações disponíveis.
Figura 1. Esquema demonstrando o funcionamento do Poll Periódico.
Criando nosso projeto
Para demonstrarmos um exemplo de código que implementa esse comportamento no servidor, precisaremos criar um projeto Java dentro de um Web Container ou Application ...
