Explorando o WildFly 8

No final de 2012, a Red Hat realizou uma pesquisa pública para determinar um novo nome para o JBoss AS. A escolha foi feita através de uma enquete publicada no site da empresa que durou alguns dias, e a troca do nome para WildFly, segundo a companhia, representa uma nova fase do software, bem como o surgimento da próxima geração dos servidores de aplicação.

Assim como nas versões anteriores, o produto será mantido por um grupo de desenvolvedores no formato de código aberto e, aquilo que for implementado neste modelo e apresentar estabilidade, continuará servindo de base para o lançamento do pacote pago do servidor de aplicação que compõe a solução JBoss Enterprise Application Platform.

Entre as novidades, estão o alinhamento do produto com a plataforma Java EE 7, menor tempo para inicialização, maior economia de memória, implementação de um novo log de auditoria e o controle de acesso baseado no uso de papéis.

Neste artigo, serão comentadas todas estas características mencionadas, bem como não deixaremos de fora outras não menos importantes. Veremos que os novos recursos estão divididos em duas partes: os que dizem respeito ao funcionamento do produto, e os que atingem diretamente o cotidiano do desenvolvedor.

Para concluir, aprenderemos a realizar configurações administrativas importantes através de três formas diferentes de gerenciamento do servidor de aplicação.

Novidades no funcionamento

É óbvio que, como qualquer lançamento de software, o WildFly 8 não poderia deixar de lado novos recursos e características de funcionamento melhoradas ou não existentes nas versões anteriores do JBoss AS. Algumas delas serão detalhadas nas subseções seguintes para verificarmos o que mudou no produto.

Modos domínio e standalone

Assim como a versão 7 do JBoss AS, o WildFly conta com dois modos de funcionamento: o standalone, baseado em um único processo da JVM; e domínio, baseado em vários processos da JVM, executados em um ou mais hosts.

O gerenciamento do funcionamento do servidor é feito de forma bastante parecida nos dois casos, porém, pelo fato de possibilitar o funcionamento distribuído, o modo domínio apresenta um ponto central de administração chamado controlador de domínio (em inglês, Domain Controller).

A Figura 1 demonstra um cenário de funcionamento do servidor no modo domínio envolvendo quatro máquinas diferentes.

Figura 1. Exemplo de funcionamento em modo domínio. Fonte: Guia de Administração do WildFly.

O Host 1 é o Domain Controller, ou seja, o gerente do cluster. Além dele, mais três máquinas escravas estão envolvidas no ambiente (Host 2, Host 3 e Host 4). Em cada uma delas, existe um Host Controller que faz a comunicação com o Domain Controller – quando alguma operação de leitura/escrita é disparada –, como também é o responsável por inicializar/parar o processo individual do WildFly.

Para possuir um cenário distribuído como o mostrado na Figura 1, no entanto, não significa que é necessário investir em hardware de alta performance.

Os desenvolvedores do servidor de aplicação afirmam que o modo domínio consome recursos mínimos de memória e processamento da máquina, e que este é um quesito em que o WildFly se diferencia dos concorrentes.

Outro recurso interessante apresentado no produto é a possibilidade de obtermos métricas de desempenho de qualquer host que faz parte do domínio. Este é um ponto importante, principalmente em cenários que envolvam infraestruturas muito grandes, pois temos como identificar máquinas que estejam com problemas de performance, ou até mesmo sofrendo possíveis ataques de hackers.

Ge ...