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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.