BT

WildFly 8: suporte total ao Java EE 7 e novo Web Server embarcado

por Charles Humble , traduzido por Diogo Carleto em 28 Fev 2014 |

A divisão JBoss da Red Hat anunciou a disponibilidade do WildFly 8, antes conhecido como JBoss Application Server. Esta versão está certificada para o Java EE7, suportando ambos Web e Full profiles. O WildFly também ganhou um novo servidor web completo chamado Undertow, novos recursos de segurança, e um sistema de correção para atualizações com o sistema em funcionamento.

O Undertow é um container Servlet 3.1 e um servidor para a interface de administração HTTP. O novo container inclui suporte para o HTTP Upgrade − Parte do HTTP /1.1 RFC, que permite uma conexão HTTP para ser atualizado para outro protocolo. O uso mais comum é para iniciar uma conexão web socket que permite que navegadores e outros clientes iniciem uma comunicação full duplex.

Como o HTTP Upgrade permite multiplexar vários protocolos em uma única porta HTTP, elimina-se a necessidade de múltiplas portas e simplifica a configuração de firewall. O WildFly usa somente duas portas: as chamadas JNDI e EJB são multiplexadas sobre a porta 8080 do subsistema Undertow, e o gerenciamento é multiplexado sobre a porta de gerenciamento web (9090).

O exemplo a seguir apresenta como é uma requisição inicial do EJB, uma vez que a conexão é estabelecida:

GET / HTTP/1.1
Host: example.com
Upgrade: jboss-remoting
Connection: Upgrade
Sec-JbossRemoting-Key: dGhlIHNhbXBsZSBub25jZQ==

O Undertow, então responde ao cliente dizendo que o upgrade é permitido e completou:

HTTP/1.1 101 Switching Protocols
Upgrade: jboss-remoting
Connection: Upgrade
Sec-JbossRemoting-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Depois que o socket é passado para a camada EJB do WildFly seu funcionamento é como o de uma conexão normal EJB.

Existe uma pequena sobrecarga de desempenho para processar a requisição HTTP inicial, mas uma vez feita, o desempenho deve ser exatamente o mesmo, e uma vez que o número de portas necessárias atualmente é menor o efeito global esperado é benéfico. Jason Greene, líder do WildFly e arquiteto da plataforma JBoss EAP na divisão JBoss da Red Hat disse ao InfoQ.com:

Há uma sobrecarga adicional na conexão uma vez que precisamos processar uma requisição HTTP. No entanto, a eficiência que o Undertow mantém está muito baixa. Após a requisição de upgrade ter sido executada o socket se comporta exatamente como no cenário não HTTP, assim as semânticas de desempenho são exatamente as mesmas a partir desse ponto. Uma vez que o impacto é tão baixo, deixamos está configuração por padrão. De forma inovadora, o WildFly 8 só possui 2 portas HTTP, uma para o gerenciamento e uma para uso da aplicação. Todos os outros protocolos reutilizam essas portas.

O Undertow também foi concebido para ser usado de modo embarcado. Existe uma API que pode ser usada para construir o servidor e registrar um manipulador HTTP, que processa as requisições de uma forma sem bloqueio. A seguir temos um exemplo do site undertow.io:

public class HelloWorldServer {
    public static void main(final String[] args) {
        Undertow server = Undertow.builder()
                .addListener(8080, "localhost")
                .setHandler(new HttpHandler() {
                    @Override
                    public void handleRequest(final HttpServerExchange exchange) throws Exception {
                        exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
                        exchange.getResponseSender().send("Hello World");
                    }
                }).build();
        server.start();
    }
}

O Undertow também permite inserir o código com base na API Servlet e existem alguns exemplos no GitHub.

Assim como o novo servidor web, o WildFly 8 tem melhorias de segurança consideráveis​​, com a adição de log de auditoria e regra baseada no modelo de segurança.

O sistema de auditoria foi concebido para assegurar que qualquer operação contra o modelo de gerenciamento fique gravado no log que pode ser escrito no arquivo local ou no servidor.

O WildFly vem com dois provedores de controle de acesso − o "simples" que é equivalente ao encontrado no AS 7, sendo tudo ou nada; embora o modelo Permissões com Base no Controle de Acesso (Role Based Access Control - RBAC) permite que diferentes administradores tenham diferentes permissões (por exemplo, uma permissão de monitoramento versus permissão de atualização).

O WildFly vem com sete permissões pré-definidas RBAC:

  1. Monitor: Tem a menor quantidade de permissões. Pode ler as configurações e o estado atual de execução, não pode ler os recursos ou informações confidenciais, e não pode ler o log de auditoria e recursos relacionados.
  2. Operator: Tem todas as permissões que o perfil monitor tem. Adicionalmente pode modificar o estado em tempo de execução − recarregar ou desligar o servidor, pausar/retomar uma fila JMS. Um operator não pode modificar configurações persistentes.
  3. Maintainer: Tem todas as permissões do operador. Pode modificar as configurações persistentes para implantar uma aplicação, adicionar um destino JMS e assim por diante. O maintainer pode editar quase todas as configurações associadas com o servidor e suas implantações. Entretanto, o maintainer não pode ler ou modificar informações sensíveis (como senhas), e não pode ler ou modificar informações de auditoria.
  4. Deployer: O mesmo que o maitainer, mas também é limitado apenas a alterações relacionadas à implantação. Um deployer não pode alterar configurações gerais do servidor.
  5. Administrator: Pode visualizar e modificar informações sensitivas como senhas, configurações de segurança do domínio. Entretanto, não pode fazer nada com o log de auditoria.
  6. Auditor: Tem todas as permissões do monitor. Essencialmente um perfil apenas de leitura, mas pode visualizar e modificar as configurações relacionadas ao sistema de log de auditoria.
  7. SuperUser: Equivalente ao administrador no AS 7 e tem todas as permissões.

O dados RBCA podem ser armazenados em praticamente qualquer servidor LDAP, incluindo o Active Directory.

WildFly também inclui um novo sistema aplicação de correções originalmente desenvolvidas para o JBoss EAP. O sistema permite implantar uma correção do JBoss remotamente ou localmente. A publicação realizada no ambiente de execução armazena o patch, mas é necessário reiniciar a aplicação para surtir efeito.

Finalmente, enquanto WildFly está focado inicialmente no suporte ao Java EE, o mesmo pode ser usado para outras linguagens e ambientes. Por exemplo, o projeto TorqueBox permite que projetos Ruby on Rails possam ser executados no servidor.

É possível encontrar mais informações no site do WildFly e também nesta gravação webinar. O InfoQ também tem uma entrevista mais extensiva com Jason Greene, na qual entre outras coisas, discutimos alguns dos antecedentes de Undertow, o novo sistema de log de auditoria e o impacto da decisão da Oracle em acabar com o suporte comercial para o GlassFish.

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 mensagens dessa discussão
Comentários da comunidade

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

Receber mensagens dessa discussão

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

Receber mensagens 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