BT

WebSocket no Java EE 7: novidades e introdução rápida

por Charles Humble , traduzido por Marcelo Cenerino em 18 Jul 2013 |

O Java EE 7 introduziu um conjunto de novas APIs e também melhorias em APIs existentes voltadas ao desenvolvimento web com HTML5. As mais importantes delas são: a nova API para processar documentos JSON, uma atualização importante no JSF para suportar novos atributos em elementos HTML, e a nova API para trabalhar com o protocolo WebSocket, o qual é uma das várias tecnologias que compõem o HTML5.

O protocolo WebSocket muda a forma como os servidores web reagem frente às requisições de seus clientes: em vez de encerrar a conexão, o servidor devolve um status 101 e mantém a conexão aberta para que ele mesmo ou o cliente possam escrever novas mensagens no fluxo de comunicação.

Ao contrário do HTTP, o protocolo WebSocket suporta comunicação full-duplex, de forma que o cliente (normalmente um navegador web) e o servidor possam trocar mensagens simultaneamente.

O protocolo WebSocket é definido pela RFC 6455 da IETF.

Para estabelecer uma conexão WebSocket, o cliente envia uma requisição de handshake, que é respondida pelo servidor, conforme mostrado no exemplo a seguir:

GET /mychat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat
Sec-WebSocket-Version: 13
Origin: http://example.com

Eis a resposta do servidor:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

Ao final do processo de handshake (ou negociação), o cliente e o servidor são conectados e ambos podem trocar mensagens, assim como encerrar a conexão.

Do lado cliente, todo o trabalho é feito com JavaScript com a API definida pela W3C para esse propósito.

As aplicações WebSocket em Java consistem de endpoints WebSocket, que são objetos que representam uma das pontas ou términos da conexão WebSocket.

A API de WebSocket do Java modela cada participante de uma sessão com o endpoint  como uma instância da interface RemoteEndpoint. Essa interface e seus dois subtipos (RemoteEndpoint.Whole e RemoteEndpoint.Partial) contêm uma variedade de métodos para enviar mensagens WebSocket a partir do endpoint para os participantes.

Existem duas formas principais de se implementar um endpoint. A primeira é implementando algumas classes da API WebSocket do Java, que contêm o comportamento exigido para controlar o ciclo de vida do endpoint, consumir e enviar mensagens, publicar-se e conectar-se a um peer:

session.addMessageHandler(new MessageHandler.Whole<String>() {
   public void onMessage(String text) {
       try {
           remote.sendText("Got your message (" + text + "). Thanks !");
       } catch (IOException ioe) {
           ioe.printStackTrace();
} }

A segunda forma é decorar uma classe POJO (comum) com algumas das anotações da API WebSocket do Java. Em tempo de execução, a implementação subjacente identifica essas classes POJO anotadas e cria os objetos apropriados para implantá-las como endpoints WebSocket.

@ServerEndpoint("/hello")
public class MyHelloServer {
@OnMessage
public String handleMessage(String message) {
          return "Got your message (" + message + "). Thanks !";

} }

A API limita a apenas um a quantidade de MessageHandlers registrados por tipo nativo de mensagem WebSocket (texto, binário, pong) em uma mesma sessão. Essa limitação pode mudar no futuro.

O endpoint participa do processo de handshake que estabelece a conexão WebSocket. Normalmente em uma conexão WebSocket o endpoint envia e recebe uma extensa variedade de mensagens. O ciclo de vida do endpoint é completado quando a conexão é finalmente encerrada.

Se uma conexão com o endpoint WebSocket deve ser encerrada por algum motivo, seja pelo recebimento de um evento de encerramento vindo do peer ou porque a implementação subjacente decidiu encerrar a conexão, a implementação WebSocket deve invocar o método onClose() do respectivo endpoint.


Antes mesmo do lançamento do Java EE 7 já era possível implementar aplicações WebSocket em Java com uma diversidade de opções disponíveis. Essas APIs eram muito diferentes, e aplicações WebSocket escritas para o Tomcat 7, por exemplo, tinham que ser modificadas para funcionar no Jetty, JBoss ou Resin. A chegada de um método padronizado de se fazer isso no Java EE é certamente muito bem-vindo.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT