Introdução ao Apache TomEE

Aprender a usar o Tomcat é relativamente simples quando já se tem conhecimentos de Java e de IDEs, como o Eclipse ou Netbeans. Existem basicamente duas formas de se instalar, considerando que o leitor seja um usuário Windows (os passos para Linux ou outros sistemas operacionais também são fáceis). Uma se dá através da descompactação de um arquivo zipado. A outra através do download de um executável em nível de S.O., que no final irá gerar registros de binário no S.O., possibilitando acesso via prompt de comando aos executáveis do mesmo software. Independente da versão adotada, usar o Tomcat é bem mais simples que outros servidores JEE que encontramos por aí.

A definição comum de container diz que o Tomcat não constitui um servidor JEE completo. Isso porque todos os servidores JEE, que se digam JEE e que sejam aceitos pela comunidade e pela Oracle, devem atender à especificação JEE, o que sugere o conceito de universalidade de implementação e execução dos projetos Java Web. A especificação determina a forma como as empresas devem prover aquela tecnologia aos seus usuários, isto é, ela taxa o mínimo necessário para que o software atenda aos requisitos mínimos daquela versão do JEE em específico. Hoje temos inúmeros servidores que atendem a esta especificação, tais como Glassfish (servidor oficial), JBoss AS, IBM WebSphere, etc. O Tomcat, por sua vez, é chamado apenas de container porque ele atende em parte à especificação JEE. Sua implementação foi feita para aceitar espeficações como a dos Servlets e JSPs. É possível também trabalhar com recursos acoplados aos frameworks como o JSF ou de injeção de dependência, apenas adicionando as bibliotecas específicas ao classpath do projeto. Entretanto, a partir do momento que precisamos "distribuir" nossa aplicação através de recursos como o Enterprise Java Beans (EJBs), ou filas com JMS, já se torna mais complicado.

Diante desse cenário, a Apache Software Foundation, empresa responsável pelo projeto Tomcat pensou em criar uma especificação própria do servidor JEE. É aí onde nasce o TomEE, que é uma abreviação de Tomcat + Java EE.

Mas qual é a diferença do TomEE para os outros servidores?

Uma gama de servidores de aplicativos usam Tomcat para fornecer funcionalidade de servlet, e isso não é uma coisa ruim - o Tomcat é grande servlet container. A abordagem da TomEE é diferente - em vez de incorporar o Tomcat em um servidor de aplicativos, o TomEE incorpora as tecnologias EJB, CDI e as outras features do Java EE dentro do Tomcat, resultando em um servidor Web Profile totalmente compatível, mas mantendo o Tomcat como o servidor mestre. O pacote TomEE é criado descompactando o Tomcat, adicionando os jars específicos e adicionando um único listener a "conf/server.xml" e zipando tudo novamente.

Apache TomEE visa fornecer aos desenvolvedores de aplicativos com uma pilha de tecnologias que podem ser implantadas em um container Java EE simples e leve. Com o TomEE, a Apache espera mudar a forma como desenvolvemos de forma rápida no mundo JEE, com a utilização de todos os recursos que antes eram impossíveis de serem usados apenas com um Tomcat simples. Talvez você possa reconhecer o TomEE de seu projeto pai, o OpenEJB. O TomEE começou como um tentativa de integração do Tomcat com o OpenEJB, mas essa definição revelou-se estreita. O próprio EJB é uma especificação extensa, incluindo suporte para a maioria das especificações Java utilizadas nas empresas de desenvolvimento. Mas o TomEE foi construído em cima da integração do OpenEJB com o JMS, serviços Web, conectores, Servlets, JPA, JDBC, Java Transactions e Segurança, adicionando suporte para ActiveMQ, CXF, MyFaces e OpenJPA, etc.

Algumas literaturas definem que o servidor foi desenvolvido com base em algumas premissas, tais como:

• Não mexa com Tomcat
• Mantenha-o simples
• Evite sobrecarga de arquitetura

Ao adicionarmos recursos para o Tomcat é importante que o TomEE não perca a "identidade Tomcat". O mecanismo de implantação é o mesmo que o Tomcat comum (apenas "exploda" o arquivo .war na pasta /webapps). Os recursos trabalham da mesma forma - você pode usar o arquivo de configuração do TomEE, mas os recursos definidos no server.xml ou context.xml dentro do seu aplicativo ainda funcionam. Coisas que antes eram impossíveis ou necessitavam grandes esforços de trabalho agora são muito mais simples, como desenvolver todos os conceitos de segurança do Java EE como WebServices ou segurança EJB perfeitamente no Tomcat Realms, por exemplo.

O objetivo era adicionar recursos Enterprise para Tomcat, sem incorrer em requisitos de tempo de execução adicionais ou tempo de inicialização de aplicativos maiores. Com base em benchmarks publicados recentemente para TomEE 1.0, parece que eles conseguiram. As estatísticas a seguir comparar os tempos de início de aplicações no TomEE versus outros ambientes de implantação:

• Rails 3.3 Personalizado (WAR 44MB): 21,3% de beta2 - tempo de inicialização (369% mais rápido);
• Aplicativo de exemplo de elevação / Scala (WAR 23MB): 43,8% de beta2 - tempo de inicialização (128% mais rápido)
• Confluence 3.5.5 (149mb descompactado): 37,6% de beta2 - tempo de inicialização (166% mais rápido)

TomEE Plus

Não é nenhum segredo que a pilha de tecnologias Java EE é muito grande. Isto traz uma série de desafios, mas pode torná-lo especialmente difícil para o Apache, por exemplo, que não pode necessariamente arcar com a sobrecarga de infraestrutura de implementação de um full-stack de aplicativos Java EE. Assim, com o Java 6, a JCP apresentou os "perfis de certificação Java EE".

Até o momento, existem duas classificações de certificação: Java EE 6 Full Profile) e Java EE 6 Web Profile. Servidores de aplicação comercial Java EE, como o Oracle Application Server, Oracle WebLogic e IBM WebSphere, bem como os servidores de aplicação JBoss e Glassfish, são totalmente certificadas. O TomEE é atualmente certificado apenas em relação ao Web Profile. Isso significa que o TomEE suporta um subconjunto das especificações Java EE que se aplicam particularmente ao desenvolvimento web Java, ou seja: CDI, EJB, JPA, JSF, JSP, JSTL, JTA, Servlet API, JavaMail, e Bean Validation.

Se seu aplicativo requer apenas essas tecnologias, então você pode tirar vantagem desse container que é leve e de baixa sobrecarga. Projetos que precisam de um pouco mais podem considerar o uso do TomEE+, que não é certificado neste momento. Ele inclui suporte à tecnologia SOAP e aos serviços Web RESTful, bem como JMS e à Java EE Connector Architecture. Veja na seção Links a página inicial do OpenEJB para uma matriz de atualização comparando recursos disponíveis no Tomcat, TomEE, TomEE Plus e OpenEJB.

Há outras duas implementações diferentes do Apache TomEE disponíveis: Webprofile e JAX-RS. O Webprofile fornece a menor distribuição (apenas 27MB) e é totalmente compatível com o Java EE Web Profile. A JAX-RS constrói sobre o Web Profile, acrescentando o suporte a JAX-RS com uma versão reduzida do Apache CXF, e é também certificada em Web Profile.

A Tabela 1 demonstra as diferentes features disponíveis para as três implementações em questão.

Tabela 1. Features implementadas pelas diferentes versões do TomEE

Instalação e Configuração

Depois de ter baixado o TomEE ou o TomEE+, descompacte-o em um diretório em seu computador. Assim como o Tomcat, o TomEE requer que você instale uma versão recente do Java Development Kit, e configure uma variável de ambiente JAVA_HOME, que deve apontar para a raiz do diretório em que você instalou o JDK. Adicione o diretório JAVA_HOME/bin à sua variável de ambiente PATH.

Você pode definir o JAVA_HOME no Windows com o comando demonstrado na Listagem 1 (supondo que você instalou o JDK em C:\Arquivos de programas\Java).

Listagem 1. Comando Windows para configurar a variável de ambiente JAVA_HOME

set JAVA_HOME="C:\Program Files\Java" set PATH=%PATH$;%JAVA_HOME%\bin

Note que se você estiver usando o Windows e não quiser executar este comando para cada novo prompt de comando, você pode configurar uma variável de sistema e de ambiente em nível de usuário através da configuração do sistema no painel de controle. Para isso, basta acessar o menu "Painel de Controle > Sistema > Configurações avançadas do sistema" (para usuários Win 7 ou superior). Após isso, selecione a opção "Variáveis de Ambiente..." na aba "Avançado" da janela que se abrirá. No final, a janela mostrada na Figura 1 estará disponível para que o usuário possa cadastrar as variáveis de usuário e de sistema.

Figura 1 - Configurando variável de ambiente JAVA_HOME

Depois de ter instalado o JDK e o TomEE descompactado localmente, então você pode começar no TomEE executando o startup.bat ou arquivo startup.sh do diretório bin do TomEE. Como o Tomcat, o TomEE escreve seus logs padrão em logs/catalina.out. Se tudo for iniciado corretamente, você deve ver algo como o listado na Listagem 2 em seu arquivo de log.

Listagem 2. Log do TomEE quando da sua inicialização

Jan 10, 2013 02:52:10 PM org.apache.catalina.core.AprLifecycleListener init Jan 10, 2013 02:52:13 PM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["http-bio-8080"] Jan 10, 2013 02:52:14 PM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["ajp-bio-8009"] Jan 10, 2013 02:52:18 PM org.apache.openejb.server.ServiceLogger <clinit> INFO: can't find log4j MDC class Jan 10, 2013 02:52:18 PM org.apache.openejb.OpenEJB$Instance <init> INFO: ... Jan 10, 2013 02:52:43 PM org.apache.myfaces.webapp.AbstractFacesInitializer initFaces WARNING: No mappings of FacesServlet found. Abort initializing MyFaces. Jan 10, 2013 02:52:43 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["http-bio-8080"] Jan 10, 2013 02:52:43 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["ajp-bio-8009"] Jan 10, 2013 02:52:43 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 15197 ms

A mensagem de inicialização ao final é bem semelhante à do Tomcat e o tempo de inicialização também é bem considerável em comparação com outros servidores.

Em contrapartida, o arquivo de log do TomEE é muito maior do que um arquivo de log tradicional do Tomcat porque ele está iniciando muito mais serviços do que o Tomcat. Uma mensagem informativa que afirma "inicialização do servidor em xxx ms" indica que o servidor foi iniciado com sucesso. Para validar se o TomEE está em execução, abra um navegador da Web para o contexto web "TomEE" na máquina em que TomEE está em execução, como por exemplo:

http://localhost:8080/tomee/

Você deverá ver algo semelhante à tela mostrada na Figura 2.

Figura 2 - Interface de acesso ao TomEE

A partir desta página, você pode clicar em "Testar a configuração" para garantir que tudo está funcionando. Esta suíte de teste primeiro verifica se o diretório do ambiente openejb está devidamente configurado. Em seguida, testa se as classes OpenEJB foram carregadas e inicializadas, e se o JNDI está funcionando. Se todos os testes passarem, então você está pronto para começar a implantar seus aplicativos no TomEE.

Application Deployment com TomEE

Implantar artefatos de aplicativo no TomEE é muito semelhante à implantação do Tomcat: basta copiar o arquivo WAR ou EAR para a pasta Tomee/webapps. Quando o TomEE vê seu arquivo WAR ou EAR, ele vai explodir o seu arquivo em um diretório com o mesmo nome, mas sem as extensões mencionadas.

O TomEE suporta um novo recurso introduzido com o Java EE 6, que é a capacidade de implantar seus EJBs e artefatos da web em um único arquivo da Web (o arquivo WAR). O objetivo é permitir que sua aplicação web e seus EJBs compartilhem o mesmo carregador de classes (classloader) e bibliotecas de terceiros (como a Spring), e para permitir que servlets possam ver as classes EJB e EJBs vejam as classes de servlet. Para fins de empacotamento, os arquivos web.xml e ejb-jar.xml convivem no mesmo arquivo WAR.

Este esquema de empacotamento novo é uma grande diferença para a J2EE e até mesmo Java EE 5, que tanto exigiu uma separação estrita entre EJBs e código Web. Se você ainda precisa dessas camadas de separação, você pode empacotar o arquivo WAR e arquivos EJBs JAR dentro de um arquivo EAR. Se você não precisa da separação, no entanto, é mais performático e muito mais fácil de configurar todas as classes no mesmo arquivo ao mesmo tempo compartilhando o mesmo classloader.

Definindo recursos externos

Um aplicativo corporativo seria bastante inútil se nunca interagisse com os recursos externos. Há duas estratégias básicas para a definição de recursos:

• Container gerenciado
• Aplicação gerenciada

Os recursos dos containers geridos são configurados no próprio container, fora do próprio aplicativo. A aplicação posteriormente adquire esses recursos do container quando se precisa deles. Recursos de aplicativos gerenciados são definidos no nível de aplicação, geralmente através de arquivos de configuração. Eles são ligados à aplicação em carregamento ou quando necessário.

A vantagem dos recursos de containers gerenciados é que o mesmo aplicativo pode ser executado em diferentes ambientes, com apenas algumas simples alterações de configuração de ambiente. Por exemplo, em um ambiente de Qualidade (QA), um aplicativo pode ser configurado para manter os dados de e para um banco de dados de controle de qualidade e publicar mensagens aos tópicos QA, mas em um Ambiente de Teste de Aceitação (ATA) de usuários desses recursos externos seriam diferentes. Tendo a configuração de ambiente realizada no container, o risco de a aplicação inadvertidamente apontar para o ambiente errado (tais como a implantação de uma aplicação para um ambiente de produção, que aponta para uma base de dados de QA) é reduzido. Finalmente, a maioria das ferramentas de monitoramento fornece a capacidade de descobrir automaticamente os recursos dos containers geridos que publicam métricas de recursos via Java Management Extensions (JMX). A maioria das equipes de apoio à produção de médio para aplicações em larga escala configura recursos no nível do container.

Os benefícios para a definição de recursos dentro do aplicativo estão principalmente relacionados à facilidade de implantação. É muito mais fácil implantar um aplicativo que sabe sobre todas as suas dependências que um cuja coleção de recursos deve ser definida externamente. Alguns projetos contornam esta situação através da combinação das duas abordagens, por exemplo, o aplicativo pode definir o recurso, como a configuração de um pool de conexões de banco de dados, mas, em seguida, extrair a URL JDBC a partir do ambiente de implantação.

É possível utilizar o Tomcat como um servidor corporativo. Os motivos para se chegar a esse ponto devem ser discutidos entre a equipe, de preferência com um profissional com experiência no Tomcat e no TomEE. Assim como todo projeto e tecnologia nova, implicações sempre existirão no uso das mesmas. Os fatores que influenciam o uso desse container no seu projeto só poderão ser mensurados em tempo real, ou seja, a partir de cases de teste por parte da equipe de arquitetura ou dos programadores mais experientes. Você mesmo como usuário básico já pode fazer seus próprios testes e ver como o mesmo lida com tudo que foi discutido aqui.

Links

http://tomee.apache.org/

http://openejb.apache.org/comparison.html