Atenção: esse artigo tem um vídeo complementar. Clique e assista!

A versão 5 do JBoss Application Server, que a partir desse momento chamaremos simplesmente AS5, foi resultado de uma maratona de três anos de pesquisas e desenvolvimento que culminou em um total redesenho da arquitetura interna do servidor de aplicações.

Essa versão marca o início de uma nova era para o servidor de aplicações mais popular, querido e utilizado do mundo. Não se trata apenas de uma nova versão do servidor de aplicações, mas de todo um ambiente em estado da arte para execução da próxima geração de projetos desenvolvidos pela JBoss.

Sobre a JBoss

JBoss, apesar de ser sinônimo de servidor de aplicações, não está restrito apenas a isso. A comunidade JBoss (www.jboss.org) possui hoje mais de 35 projetos. Entre eles, podemos destacar:

Hibernate – o framework de persistência ORM (Object Relational Mapping) mais utilizado do mundo e que muito influenciou a especificação de EJB 3.0.

JBoss Seam – o framework que combina o que há de melhor em desenvolvimento Web 2.0 com o novo modelo de componentes de negócio EJB 3.0, aumentando a produtividade e disponibilizando inúmeros componentes para facilitar e acelerar o desenvolvimento de aplicações corporativas em Java. O reconhecimento do poder do JBoss Seam por parte da comunidade deu origem à JSR 299 – Web Beans. Ver Edição 58.

Além de influenciar o futuro da plataforma Java EE, seja com participações nas JSR's, seja com a implementação de referência de JSR's, a JBoss conta hoje com a participação de brasileiros, funcionários da Red Hat Brasil, como principais desenvolvedores em diversos projetos da comunidade JBoss, dedicando-se em tempo integral a atividades de desenvolvimento e suporte a clientes. Dentre esses projetos, podemos destacar: o próprio JBoss AS, o JBoss Rules – motor de regras e BRMS (business rule management system), JBoss AOP – framework para AOP (programação orientada a aspectos), JBoss SX (framework de segurança da JBoss), JBoss Profiler (ferramenta de profiling baseada em log), JBoss Messaging (JMS provider), JBoss ESB (para integração SOA, ver Edição 59) e JBoss Portal (solução para portais corporativos).

Mais detalhes sobre esses e outros projetos JBoss (como o JBoss jBPM, JBoss Tools, Teiid) podem ser encontrados no site: www.jboss.org.

Apesar de os projetos JBoss serem conduzidos, em sua maior parte, por funcionários da Red Hat/JBoss, é inegável a contribuição da comunidade durante todos esses anos de existência da jboss.org. Essa contribuição é de extrema importância para a sobrevivência e qualidade dos projetos.

A contribuição não é feita apenas com desenvolvimento de código fonte, mas também com participação em fóruns de discussão, relato de bugs, pedido de novas funcionalidades, elaboração/tradução de documentação, blogs pessoais, eventos organizados pela comunidade, etc.

Veja os links de referência para saber mais informações sobre como contribuir com a comunidade JBoss.

Novidades

Uma das novidades da versão 5 do JBoss AS é a compatibilidade total à especificação Java EE 5. Apesar de a versão 4.x já suportar grande parte da especificação Java EE 5 (EJB 3.0, JPA, JAX-WS, etc.) e ser um dos primeiros servidores de aplicações a suportar a especificação de EJB 3.0, o suporte à Java EE 5 não era completo nem certificado. A certificação era uma característica bastante requisitada por clientes corporativos da Red Hat, principalmente em relação à garantia de compatibilidade das aplicações desenvolvidas.

O suporte ao JDK 6 é também uma novidade dessa versão. Apesar de suportar o Java 6 desde a versão 4.2, é na versão 5 que esse suporte foi aprimorado e tornou-se padrão para execução do servidor de aplicações.

Além da certificação Java EE 5 e do suporte ao Java 6, o destaque dessa versão, sem dúvida nenhuma, fica a cargo do JBoss Microcontainer. O AS5 faz parte de uma nova geração do servidor de aplicações, construído com base no novo JBoss Microcontainer.

O JBoss Microcontainer é resultado de uma completa reescrita do JBoss JMX Microkernel (utilizado nas versões das séries 3.x e 4.x do JBoss AS) e o substitui completamente para suportar a utilização direta de POJOs e o uso como um projeto independente do servidor de aplicações JBoss, seguindo a tendência e evolução do desenvolvimento Java EE com a utilização de novos paradigmas como AOP, injeção de dependência e inversão de controle, e o foco na utilização de POJOs (como EJB 3.0, JPA, Spring, Guice, entre outros).

O servidor de aplicação JBoss 3/4 era basicamente uma série de MBeans agrupados, controlados e disponibilizados pelo Microkernel, o qual já possibilitava grande flexibilidade para retirar e adicionar novos MBeans.

Já com o JBoss Microcontainer é possível desenvolver serviços do servidor de aplicações baseados em POJOs. Não é mais necessário desenvolver MBeans.

O AS5 utiliza o JBoss Microcontainer para fazer a integração dos serviços disponibilizados pelo servidor de aplicações, entre eles: container Servlet/JSP; container EJB; gerenciador de deploy, entre outros, disponibilizando, assim, um ambiente Java EE padrão. O JBoss AS não é um servidor de aplicações monolítico – com um único kernel fornecendo os serviços requeridos pela especificação Java EE – mas sim, uma coleção de componentes independentes e interconectados, cada um deles com foco em uma funcionalidade específica requerida pela especificação Java EE. Essa arquitetura flexível possibilita que novos serviços possam ser facilmente adicionados e os serviços desnecessários possam ser removidos. Se houver necessidade de um serviço adicional, simplesmente fazemos o deploy do serviço desejado. De maneira análoga, se não precisamos de um serviço, podemos simplesmente removê-lo. A Figura 1 mostra uma visão geral de como os serviços são associados e disponibilizados pelo Microcontainer.

Figura 1. Uma visão geral da arquitetura de serviços que são disponibilizados pelo Microcontainer

Como resultado, temos um servidor de aplicações totalmente customizado às nossas necessidades, com o uso eficaz de recursos do servidor físico (CPU, memória, disco).

A flexibilidade é tamanha, que os serviços construídos com base no JBoss Microcontainer podem ser utilizados de maneira independente em outros ambientes/servidores de aplicações não JBoss, como o GlassFish, ou até mesmo o Tomcat. Como exemplo, podemos citar o suporte total ao EJB 3.0 no Tomcat (bastando para isso, fazermos o deploy do JBoss EJB 3.0 container no Tomcat).

Como o JBoss Microcontainer é extremamente leve, pode ser utilizado para disponibilizar serviços até mesmo em um ambiente Java ME. Desse modo, abre-se um novo horizonte de possibilidades para aplicações móveis que passam a usufruir dos serviços “enterprise”, sem a necessidade de utilização de um ambiente/servidor Java EE completo.

O JBoss Microcontainer utiliza o conceito de injeção de dependências (IoD) para interconectar e disponibilizar os serviços do servidor de aplicações. Além disso, pode ser utilizado como container de injeção de dependências de propósito geral ao estilo Pico Container e Spring.

Como amplamente consolidada no Java 5, toda configuração do JBoss Microcontainer pode ser realizada através de anotações ou XML, dependendo do local onde a informação de configuração está localizada (classes Java ou arquivos de configuração).

Além de tudo isso, o JBoss Microcontainer possui classes de testes utilitárias que estendem o JUnit e tornam a configuração e a execução de testes unitários uma tarefa extremamente simples, permitindo que o desenvolvedor acesse POJOs e serviços nas classes de testes com apenas algumas linhas de código.

Todo o mecanismo de classloader do JBoss AS também foi modificado para utilizar o avançado conceito do Virtual Deployment Framework (VDF). O VDF foi desenvolvido para abstrair, simplificar e unificar a manipulação de arquivos pelo servidor de aplicações.

Denominado Virtual File System (VFS) Class Loader, esse novo mecanismo de classloader, além do uso do VDF para localizar bibliotecas e classes, faz uso extensivo de AOP para “aspectizar” o deploy de aplicações/serviços no servidor de aplicações.

O VFS faz a análise dos deploys produzindo meta-informações que serão utilizadas pelo JBoss Microcontainer para instanciar, interconectar e controlar o ciclo de vida e dependência dos deploys. O JBoss Microcontainer utiliza uma máquina de estados para garantir que toda e qualquer dependência do deploy seja satisfeita antes de disponibilizar o serviço.

Modularização dos serviços – Maior possibilidade de escolha e flexibilidade

Um grande avanço do AS5 foi a modularização dos serviços internos do servidor de aplicações em projetos independentes.

Essa modularização não traz impactos diretos para o usuário final, mas faz parte de uma importante estratégia da JBoss em disponibilizar os vários serviços Java EE como projetos independentes. Assim, esses serviços podem ser consumidos a la carte em diferentes ambientes, e não apenas no próprio servidor de aplicações, o que permite grande flexibilidade e liberdade de escolha. Remover serviços é tão simples quanto adicionar novos.

Muitas das principais funcionalidades do AS5 são providas da integração de vários outros projetos JBoss, entre eles:

• JBoss EJB 3.0 – Implementação da última versão da especificação EJB 3.0 – A especificação de EJB 3.0 faz parte de uma total reestruturação da especificação EJB. E tem por objetivo a simplificação do desenvolvimento;

• JBoss Messaging – Reescrita completa do antigo JBossMQ (que é o provedor JMS padrão no JBoss AS das séries 4.x). É uma implementação de JMS de alta performance compatível com a JSR-914, com suporte out-of-the-box a cluster de filas e tópicos, com tolerância a falhas transparente e um sistema de redistribuição de mensagens inteligente. É hoje o provedor de mensageria padrão do AS5, além de ser parte integrante da infraestrutura do JBoss ESB;

• JBoss Cache – É a implementação de cache utilizada no AS5. É utilizado principalmente em conjunto com o JGroups para fornecer uma solução completa de cluster. Entre as diversas características está o buddy replication: permite que o cache seja replicado apenas para um “buddy” (companheiro) no cluster, evita a sobrecarga de outros nós no cluster sem necessidade, realiza uma espécie de backup do estado do nó;

• JBoss WS – Implementação da pilha de web services compatível com a especificação JAX-WS 2.0/JAX-RPC.

Além de implementar toda a especificação de Web Services, foi criada uma camada de abstração que possibilita que se pluguem outras implementações. Por exemplo: podemos utilizar a implementação nativa do JBoss WS, o Metro (implementação de web services da Sun), ou ainda o CXF (implementação da Apache), sem qualquer tipo de impacto sobre o JBoss AS. Assim, o usuário tem total liberdade para escolher a implementação que melhor se adapta às suas necessidades.

No final do mês de março, foi anunciado que os esforços serão focados em uma única implementação: JBossWS-CXF, ou seja, as próximas versões do JBoss AS virão com o CXF nativo. Aqueles que usam o JBoss WS nativo não precisam se preocupar, pois a transição será realizada gradativamente e trará grandes benefícios, principalmente no que diz respeito a soluções SOA;

• JBoss Transactions – é o gerenciador de transações padrão no AS5. O JBoss Transactions foi adquirido em 2005 da Arjuna/Hewlett-Packard – um gerenciador de transações extremamente rápido e robusto. Resultado de mais de 18 anos de experiência dos seus criadores em gerenciamento de transações, foi a primeira implementação de JTA e JTS do mercado;

• JBoss Web – É o container Web/Servlet do AS5, comumente conhecido como "Tomcat on stereoids". Tem sua implementação baseada no Apache Tomcat 6.0 e inclui suporte a conectores baseados no Apache Portable Runtime (APR) para alcançar maior performance e escalabilidade, podendo, em alguns casos, equiparar-se ao Apache HTTP Server ou até superá-lo;

• JBoss Security – Além do suporte a JAAS, foi atualizado para suportar mecanismos de autorização plugáveis: SAML, XACML e SSO.

A Tabela 1 compara os principais serviços utilizados no AS5 e no seu sucessor (JBossAS 4.2.3), para facilitar a visualização da evolução de versões entre os dois.

O AS5 suporta nativamente POJOs, MBeans e OSGi bundles (com ajuda do Apache Felix). Suportar um novo modelo de componentes é tão simples quanto implementar uma nova fachada para o JBoss Microcontainer. Isso permite que o JBoss AS suporte qualquer outro modelo de componentes existente ou que ainda está por vir; já está preparado, portanto, para o sistema de módulos que será implementado no Java 7.

Tabela 1. Matriz de comparação de versão entre o JBossAS 4.2.3 e o JBossAS 5

Novidades em Cluster

Uma das melhorias no AS5 foi a criação de um novo mecanismo de integração entre o JBoss Cache e o Hibernate/JPA para a utilização de Second Cache Level (ou cache L2, introduzido no Hibernate 3.3). Existem basicamente quatro tipos de objetos que podem participar de um Second Cache Level: entidades, collections, resultados de query e timestamps. Nas versões 4.x, apenas um único cache podia ser utilizado para armazenar todos os tipos de objetos, causando dificuldades na consulta. Com o AS5 existe um cache diferenciado para cada tipo de objeto, evitando assim sobrecarga e lentidão na busca de objetos na árvore de cache.

Essa versão também permite buddy replication de Stateful Session Beans. Com buddy replication, é possível diminuir a carga de memória e o tráfego na rede. A Figura 2 mostra uma arquitetura com seis nós, onde cada nó possui os seus dados e um cache do nó anterior. Quando ocorre queda de um dos nós, automaticamente o nó que possuía o cache do nó em queda assume o comando, guardando também o cache do nó anterior, fechando o círculo. A Figura 3 mostra a queda do servidor nó 1 e o servidor nó 2 assumindo o cache do nó 1 (em queda) e 6.

Figura 2. Arquitetura com buddy replication

Figura 3. Arquitetura com buddy replication e queda do nó 1

Nas versões 4.2.x, buddy replication era configurada no arquivo $JBOSS_HOME/server/all/deploy/jboss-web-cluster.sar/META-INF/jboss-service.xml (apenas camada web). Já o AS5 centraliza toda a configuração de cache no serviço chamado Cache Manager, que está localizado em $JBOSS_HOME/server/all/deploy/cluster/jboss-cache-manager.sar.

Com a utilização do JBoss Messaging em vez do JBossMQ, a clusterização do provider de mensageria também mudou. O antigo JBossMQ era executado em modo HA-Singleton, ou seja, apenas uma instância de JBoss executava o provider de mensageria por vez. Com o JBoss Messaging, é possível ter todos os nós ativos para o serviço de mensageria, proporcionando um balanceamento de carga entre os diversos nós, caso ocorra uma sobrecarga no servidor. Para que as filas sejam consideradas “clusterizadas”, é necessário adicionar o atributo Clustered com valor True na declaração da Queue ou Topic, conforme mostra a Listagem 1.

Listagem 1. $JBOSS_HOME/server/all/deploy/cluster/jboss-cache-manager.sar

<mbean code="org.jboss.jms.server.destination.QueueService" name="jboss.messaging.destination:service=Queue,name=testDistributedQueue" xmbean-dd="xmdesc/Queue-xmbean.xml"> <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends> <depends>jboss.messaging:service=PostOffice</depends> <attribute name="Clustered">true</attribute> </mbean>

A configuração do serviço de portas também mudou. Com a utilização de POJOs e AOP no Microcontainer, as portas agora são injetadas conforme a necessidade da configuração.

O serviço ServiceBindingManager é o responsável por fazer a associação entre as portas e cada um dos serviços, por exemplo, HTTP na porta 8080, AJP na porta 8009, etc. Na versão 5.0, ocorre uma chamada ao arquivo bootstrap.xml (Listagem 2), que é o responsável por carregar algumas configurações em tempo de inicialização. O bootstrap.xml está configurado para utilizar o arquivo de configuração de portas bindings.xml, o qual já possui algumas configurações pré-definidas que podem ser utilizadas e customizadas conforme a necessidade do usuário. A Listagem 3 mostra a injeção das configurações de portas disponíveis. No caso, estão sendo injetadas as configurações de PortsDefaultBindings, Ports01Bindings, Ports02Bindings e Ports03Bindings. A definição das configurações PortsDefaultBindings e Ports01Bindings é realizada com a injeção de beans do tipo ServiceBindingSet (Listagens 4 e 5). O trecho referente a port offset atua diretamente na configuração de StandardBindings (Listagem 6), realizando uma somatória no valor de cada porta. No caso, o PortsDefaultBindings irá manter as configurações conforme estão no arquivo, pois seu port offset está definido com valor 0, porém a configuração Ports01Bindings irá somar 100 em cada uma das portas. Portanto, para o Ports01Bindings, a porta 1099 será 1199, a porta 1098 será1198, a porta 8080 será 8180, e assim por diante.

$JBOSS_HOME é o diretório de instalação do JBoss AS5.

$PROFILE é o diretório referente ao profile/configuração, por exemplo: default, all, web, etc.

Listagem 2. $JBOSS_HOME/server/$PROFILE/conf/bootstrap.xml

<bootstrap xmlns="urn:jboss:bootstrap:1.0"> <url>bootstrap/vfs.xml</url> <url>bootstrap/classloader.xml</url> <url>bootstrap/aop.xml</url> <url>bootstrap/jmx.xml</url> <url>bootstrap/deployers.xml</url> <url>bootstrap/bindings.xml</url> <url>bootstrap/profile-repository.xml</url> </bootstrap>

Listagem 3. Trecho do arquivo bindings.xml – definição de alias

<bean name="ServiceBindingStore" class="org.jboss.services.binding.impl.PojoServiceBindingStore"> <!-- Base bindings that are used to create bindings for each set --> <property name="standardBindings"><inject bean="StandardBindings"/></property> <!-- The sets of bindings --> <property name="serviceBindingSets"> <set> <inject bean="PortsDefaultBindings"/> <inject bean="Ports01Bindings"/> <inject bean="Ports02Bindings"/> <inject bean="Ports03Bindings"/> </set> </property> </bean>

Listagem 4. Trecho do arquivo bindings.xml – definição de PortsDefaultBindings

<bean name="PortsDefaultBindings" class="org.jboss.services.binding.impl.ServiceBindingSet"> <constructor> <!-- The name of the set --> <parameter>ports-default</parameter> <!-- Default host name --> <parameter>${jboss.bind.address}</parameter> <!-- The port offset --> <parameter>0</parameter> <!-- Set of bindings to which the "offset by X" approach can't be applied --> <parameter><null/></parameter> </constructor> </bean>

Listagem 5. Trecho do arquivo bindings.xml – definição de Ports01Bindings

<bean name="Ports01Bindings" class="org.jboss.services.binding.impl.ServiceBindingSet"> <constructor> <!-- The name of the set --> <parameter>ports-01</parameter> <!-- Default host name --> <parameter>${jboss.bind.address}</parameter> <!-- The port offset --> <parameter>100</parameter> <!-- Set of bindings to which the "offset by X" approach can't be applied --> <parameter><null/></parameter> </constructor> </bean>

Listagem 6. Trecho do arquivo bindings.xml – definição de StandardBindings – portas padrão

<bean name="StandardBindings" class="java.util.HashSet" elementClass="org.jboss.services.binding.ServiceBindingMetadata"> <constructor> <parameter> <set> <!-- ********************* conf/jboss-service.xml ****************** --> <!-- Naming Service --> <bean class="org.jboss.services.binding.ServiceBindingMetadata"> <property name="serviceName">jboss:service=Naming</property> <property name="bindingName">Port</property> <property name="port">1099</property> </bean> <bean class="org.jboss.services.binding.ServiceBindingMetadata"> <property name="serviceName">jboss:service=Naming</property> <property name="bindingName">RmiPort</property> <property name="port">1098</property> </bean> . . . </set> </parameter> </constructor> </bean>

As portas padrão do JBoss Application Server são definidas no bean StandardBindings, o qual realiza a associação de cada porta a cada serviço específico. A Listagem 6 mostra um trecho da declaração do StandardBindings, em que o serviço Naming (JNDI) está sendo associado à porta 1099 e à porta RMI 1098.

Com a utilização do ServiceBindingManager, torna-se mais fácil a utilização de várias instâncias de JBoss AS no mesmo servidor físico. Desse modo, a configuração de portas é mantida em um único lugar, o que facilita a manutenção.

Injeção de POJOs utilizando o Microcontainer

Os arquivos que terminam com jboss-beans.xml são utilizados pelo Microcontainer para realizar a injeção de POJOs. São semelhantes aos -service.xml que eram utilizados nas versões 4.x. A maioria dos serviços do AS5 já foi convertida para POJOs. Porém, ainda restam alguns MBeans das versões antigas que utilizam os -service.xml, os quais serão substituídos em versões futuras.

Para facilitar o entendimento da injeção de POJOs realizada pelo Microcontainer, criamos a classe PojoServiceExample (Listagem 7). É uma classe muito simples, com apenas um método construtor que imprime uma mensagem na tela. A Listagem 8 mostra o arquivo jboss-beans.xml, o qual possui a declaração do POJO com o nome PojoServiceExample. Ao realizar o deploy, deverá ser exibida a mensagem conforme mostra a Listagem 9.

Esse exemplo mostra a forma mais simples de disponibilizar um POJO utilizando o Microcontainer. Basicamente todos os serviços, módulos e suas dependências são injetados como POJOs e manipulados dessa forma, sem a necessidade de ter de implementar uma interface ou estender uma classe abstrata.

Listagem 7. Classe PojoServiceExample

package jm.exemplos.pojo; public class PojoServiceExample { public PojoServiceExample() { System.out.println("Construtor de PojoServiceExample()"); } }

Listagem 8. Arquivo jboss-beans.xml

<?xml version="1.0" encoding="UTF-8"?> <deployment xmlns="urn:jboss:bean-deployer:2.0"> <bean name="PojoServiceExample" class="jm.exemplos.pojo.PojoServiceExample"/> </deployment>

Listagem 9. $JBOSS_HOME/server/$PROFILE/log/server.log

2009-03-04 17:10:16,060 DEBUG [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (main) Added component PojoServiceExample to vfszip:/opt/downloads/jboss-5.0.1.GA/server/default/deploy/jboss5-servico-exemplo.beans 2009-03-04 17:10:16,063 INFO [STDOUT] (main) Construtor de PojoServiceExample()

Instalação

Para a instalação, utilizaremos a versão binária da distribuição do JBoss AS. Para fazer o download do AS5, basta acessar a página de download (ver Links) e selecionar o arquivo jboss-5.0.1.GA.zip. O site JBoss.org disponibiliza também versões anteriores e um Release Notes de cada uma das versões.

Recomendamos a utilização da versão GA (General Availability), que é a versão estável da distribuição.

O único pré-requisito para execução do JBoss AS é uma máquina virtual Java (JRE) 1.5 ou superior instalada. Na versão 5, não há mais a necessidade de instalação do JDK, pois o AS5 já vem com o ECJ (compilador do Eclipse JDT), necessário para compilar JSPs.

O AS5 pode ser instalado e executado utilizando uma máquina virtual Java 5 ou 6 em qualquer Sistema Operacional. Os binários compilados com as duas JDKs estão disponíveis no site www.jboss.org. Apesar de o número de downloads do binário compilado com Java 6 ser superior e ser considerado uma versão experimental, a versão com Java 5 é a chamada versão primária e é recomendada para utilização em produção.

Caso queira rodar o AS5 compilado com JDK 5 utilizando JRE 6, quatro bibliotecas devem ser copiadas do diretório /client para o diretório /lib/endorsed. São elas:

• jbossws-native-saaj.jar;

• jbossws-native-jaxrpc.jar;

• jbossws-native-jaxws.jar;

• jbossws-native-jaxws-ext.jar.

Porém, utilizando o binário compilado com JDK 6 em uma JRE 6, nenhuma alteração é necessária.O que muda em geral é o script de inicialização de cada ambiente. Por exemplo: no Windows utilizamos run.bat, no Unix/Linux, run.sh (para simplificar, omitiremos a extensão a partir deste ponto). O processo de instalação básica do JBoss AS é extremamente simples: basta descompactá-lo em algum diretório de sua escolha.

Todo o JBoss AS e sua configuração estão contidos em uma única estrutura de diretório. Então para desinstalar o JBoss AS basta removermos todo o diretório.

Inicializando o servidor

Após a descompactação do arquivo, iremos iniciar o Application Server. Os scripts de inicialização estão localizados no diretório /bin; execute o script run. Caso esteja utilizando o Windows, execute o arquivo run.bat. O prompt de comando deverá exibir algo semelhante à Figura 4. Com isso, seu AS5 está pronto para ser utilizado.

Figura 4. Prompt de inicialização do AS5

Os arquivos de inicialização utilizarão por padrão o profile default. Veja o quadro “Explorando a nova estrutura de diretórios” para entender melhor os profiles existentes no AS5. Com o parâmetro -c, é possível inicializar diferentes profiles:

# ./run -c all

Por questões de segurança, o JBoss AS, quando executado, atende às requisições apenas na interface local (127.0.0.1). Esse comportamento faz com que o servidor não seja acessível remotamente. Para habilitar o acesso remoto ao servidor de aplicações, basta utilizarmos a opção -b <interface> no script de inicialização do servidor. O comando abaixo fará o JBoss AS executar os serviços em todas as interfaces de rede do servidor onde está sendo executado.

# run.sh -b 0.0.0.0

De qualquer maneira, esteja ciente da necessidade da correta configuração de segurança do servidor conforme a política de segurança local.

Explorando a nova estrutura de diretórios

A estrutura de diretórios do AS5 é muito semelhante à dos seus antecessores (Figura Q1). Iremos detalhar as principais diferenças entre a estrutura de diretórios de uma versão da série 4.x para a versão 5.

Ao instalar o AS5, percebe-se o novo diretório common na raiz da instalação. Nas versões anteriores, o diretório lib de cada profile (configuração) possuía praticamente as mesmas bibliotecas. Em um ambiente com diversos profiles sendo executados em paralelo, o tamanho em disco do JBoss AS aumenta consideravelmente. No AS5 as bibliotecas que são obrigatórias para o funcionamento de todos os profiles foram movidas para o diretório $JBOSS_HOME/common/lib. Esse diretório funciona como uma extensão do diretório $JBOSS_HOME/server/$PROFILE/lib, deixando-o mais limpo e de fácil manutenção, especialmente para gerenciar seus drivers jdbc ou bibliotecas específicas das aplicações.

Os outros diretórios da raiz da instalação permanecem com as mesmas funções:

• bin – possui todos os scripts e arquivos binários necessários para iniciar e parar o AS;

• client – contém bibliotecas necessárias à comunicação de uma aplicação cliente com o JBoss AS. Essas bibliotecas não são carregadas pelo JBoss AS diretamente, mas por aplicações clientes rodando em JVMs diferentes;

• docs – diretório com exemplos de configuração de Datasources, DTDs e XML schemas, licenças de bibliotecas e resultados de testes unitários. Para documentação completa do JBoss AS, acesse o site da comunidade JBoss www.jboss.org;

• lib – possui as bibliotecas necessárias para executar o “core” do AS;

• server – é um dos diretórios mais importantes e contém os profiles e as configurações para a execução de aplicações Java EE.

Figura Q1. Estrutura de diretórios da raiz do AS5

Além dos profiles clássicos das versões anteriores (minimum, default, all), dois novos profiles foram adicionados ao diretório server: web e standard. O profile web foi criado com o objetivo de executar apenas aplicações web, ou seja, JSPs e Servlets (sem a utilização de EJBs). Além disso, também estão disponíveis JTA, JCA e JPA; porém a maioria dos outros serviços não está disponível, como os serviços de e-mail, mensageria, Quartz, gerador de chaves, etc. Esses serviços só estão disponíveis a partir do profiler default. O profile standard foi criado para a execução dos testes de compatibilidade com Java EE 5. O profile default é um “superset” do standard e possui algumas poucas configurações e aplicações adicionais.

Muitos usuários se perguntam qual profile devem utilizar para executar suas aplicações. A Tabela Q1 mostra as principais diferenças entre os cinco profiles.

Os profiles mais utilizados nas versões anteriores eram o default e o all. No AS5, além destes, o profile web deverá ser utilizado em grande escala, substituindo a utilização do Tomcat e jboss-web stand-alone. Se a aplicação necessita de alta-disponibilidade (HA), utiliza-se o profile all. A maioria dos outros casos será atendida com o profile default.

Figura Q2. Estrutura de diretórios do profile “default”

Cada profile possui um diretório conf. Assim como nas versões anteriores do JBoss AS, possui as configurações gerais do servidor de aplicação, como controle transacional, log4j, diretórios de deploy, etc.

O diretório deploy é o local utilizado para publicar aplicações e disponibilizar serviços no JBoss AS.

No AS5, houve a separação dos serviços “deployáveis” com a criação do diretório deployers (Figura Q2). Assim, não ficam mais misturados no diretório deploy, sendo armazenados no diretório deployers(a exemplo do jbossweb.deployer).

O diretório lib contém bibliotecas que serão compartilhadas por todos os serviços e aplicações disponíveis para o profile. Caso queira compartilhar um driver JDBC entre várias aplicações no mesmo profile, adicione a biblioteca do drive no diretório lib.

Para o profile all, foi criado o diretório cluster, o qual armazena uma total reestruturação dos arquivos de configuração de cluster. O arquivo cluster-service.xml não existe mais, e seu equivalente é o $PROFILE/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml.

Comparação entre os profiles

Tabela Q1. Serviços disponíveis em cada profile.

JBoss AS de cara nova

O design do JMX Console e Web Console também foi atualizado para facilitar a busca de serviços. Agora, há um menu lateral esquerdo com filtro para facilitar a identificação dos serviços. Ao clicar no link, apenas os serviços relacionados serão exibidos (Figura 5). O Web Console também foi modificado, incorporando o design do JMX Console (Figura 6).

Figura 5. Novo design do JMX Console

Figura 6. Novo design do Web Console

Mitos

Acabando com o mito: O JBoss AS não tem um console unificado de administração, monitoração e controle, tudo tem de ser feito “à mão”.

Não basta ser um servidor moderno, robusto e performático se a administração não for algo simples e intuitivo. Pensando nisso, foi criado o projeto Jopr (Figura 7). O nome Jopr (pronuncia-se jopper) foi escolhido baseado no filme Jogos de Guerra (WarGames), em que havia um super computador chamado WOPR (Whopper) – War Operation Plan Response – o qual era responsável por responder a todo e qualquer ataque nuclear inimigo.

O propósito desse projeto é disponibilizar ao administrador uma interface Web integrada e intuitiva para a administração, monitoração, configuração e controle da Plataforma JBoss.

Através do Jopr é possível, entre várias outras coisas:

• Saber o consumo de CPU, memória, disco e rede do servidor;

• Saber o consumo de memória da JVM utilizada pelo servidor de aplicações;

• Visualizar e monitorar métricas do servidor de aplicações e das aplicações. (Ex: saber quantas sessões estão abertas em uma determinada aplicação);

• Realizar start/stop/restart do servidor de aplicações;

• Monitorar métricas e criar/deletar/configurar datasources, connection factories, JMS topics;

• Gerar alertas através de e-mail e/ou traps SNMP quando da ocorrência de uma condição pré-configurada (Ex: utilização de CPU ultrapassar 80%; memória da JVM ultrapassar 90%).

Além do Jopr Server – com foco em várias instâncias de JBoss AS, existe também uma versão com foco em apenas uma instância de JBoss AS chamado Embedded Jopr, o qual é disponibilizado no próprio servidor. Com o Embedded Jopr (Figura 8), é possível realizar deploys de EARs e WARs, criar novos Datasources, criar novas filas JMS, monitorar o pool de conexões, executar scripts, etc. Tudo isso utilizando uma interface Web intuitiva.

Figura 7. Jopr

Figura 8. Embedded Jopr

Conclusão

Após três anos de pesquisas e desenvolvimento, o JBoss Application Server 5 está pronto para sua grande estréia.

Com um novo kernel construído a partir do zero, substitui a utilização de MBeans por POJOs, utiliza extensamente AOP, unifica a manipulação de metadados, altera o mecanismo de classloading, “aspectiza” os deployers, tudo isso mantendo a compatibilidade com a maioria dos serviços existentes. Essas são algumas das novidades dessa nova versão.

O lançamento do AS5 é apenas o começo de uma nova era para os projetos JBoss.

A flexibilidade proporcionada pelo Microcontainer permitirá à Red Hat/JBoss, além de inovar, estar up-to-date com as especificações do JCP.

O objetivo da Red Hat/ JBoss é ter o mais inovador, robusto e performático servidor de aplicações do mercado.

As possibilidades são infinitas e a Red Hat/JBoss precisa da participação da comunidade para ajudar na definição do futuro e no desenvolvimento do JBoss AS e de todos os outros projetos. Essa contribuição é essencial para manter os projetos JBoss como os mais populares, queridos e utilizados do planeta. A comunidade é o poder do open source. Não seja apenas usuário: participe, teste, reclame, sugira, contribua.

Links

www.jboss.org
Página principal da JBoss

http://www.jboss.org/community/docs/DOC-9938
Como contribuir com a comunidade JBoss

http://java.sun.com/javaee/overview/compatibility.jsp
Listagem de Servidores de Aplicação compatíveis com Java EE 5.0

http://jcp.org/en/jsr/detail?id=244
Página da especificação Java EE 5.0

http://www.jboss.com/products/platforms/application/standards
Página de padrões suportados pelo JBoss AS

http://www.jboss.org/jbossas/downloads/
Página de download do JBoss AS

http://www.jboss.org/jopr/
Página principal do Jopr

http://felix.apache.org
Página principal do Apache Felix

http://magazine.redhat.com/2008/10/31/interview-chris-morgan-on-jopr/
Entrevista com Chris Morgan sobre Jopr

Livros

JBoss in Action, Javid Jamae e Peter Johnson, Manning Publications, 2009
Nova versão do livro JBoss in Action a qual foca nas principais configurações do JBoss Application Server 5