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.

Gerenciamento e configuração unificados

Como era de se esperar, a configuração dos recursos no WildFly está mais fácil, uma vez que foi empregada uma abordagem centralizada de gerenciamento promovida pelo Domain Controller. Nesta situação, mesmo que você esteja rodando o servidor no modo domínio, a configuração de todos os hosts envolvidos está especificada de forma organizada em um único arquivo.

Outra característica importante está na arquitetura, que foi organizada em subsistemas. A configuração deles é fácil de compreender, pois segue padrões inteligentes especificados nos arquivos XML do produto.

Isto significa que é possível excluir do servidor de aplicação os subsistemas que não forem necessários no seu ambiente. Por exemplo: se o projeto que vai rodar no WildFly não utiliza EJB, basta remover as linhas que definem o subsistema Enterprise JavaBeans do XML.

No que diz respeito às formas de gerenciamento do servidor, é possível modificar ou obter parâmetros de funcionamento através das seis maneiras, listadas a seguir:

· Alterando os arquivos internos do produto;

· Executando instruções via linha de comando;

· Acessando o console administrativo web;

· Utilizando uma API Java nativa do WildFly;

· Usando REST baseado em HTTP/JSON;

· Acessando um gateway JMX.

Servidor web de alta performance incorporado (Undertow)

Um novo servidor web de alta capacidade de processamento foi criado para atender os requisitos de performance do WildFly. Assim surgiu o projeto Undertow, um produto independente, patrocinado pela JBoss, desenvolvido em Java e totalmente baseado na API New I/O.

Entre os recursos disponíveis neste servidor web estão o suporte a Servlets 3.1 e a WebSockets, este último seguindo a especificação JSR 356.

Segundo os desenvolvedores do servidor web, ele tem a capacidade de processar milhões de conexões simultaneamente. De acordo com testes realizados pela empresa de desenvolvimento de software TechEmpower, o produto bateu concorrentes fortes de várias linguagens no quesito taxa de transferência, comprovando o poder do Undertow (confira a seção Links).

Redução no número de portas

Esta é uma alteração que facilita muito a vida da equipe de infraestrutura. Para se adaptar aos serviços de computação em nuvem – que rodam várias instâncias de máquinas virtuais em um único servidor físico –, o WildFly moveu todos os protocolos para serem multiplexados em apenas duas portas HTTP: uma para gerenciamento (9990) e outra para as aplicações (8080). " [...] continue lendo...