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.

Avalie esse artigo

Relevância
Estilo/Redação

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
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.