Web – Uma Introdução ao Desenvolvimento para a Internet com Java – Parte 02 – Técnicas para Deploy

Nesta segunda parte deste artigo serão trabalhadas outras técnicas de deploy para aplicações web.

por Everton Coimbra de Araújo

Como visto na primeira parte deste artigo (http://www.linhadecodigo.com.br/Artigo.aspx?id=2002) para distribuir uma aplicação web basta criar uma pasta no diretório de aplicações do servidor (neste caso o diretório webapps no Tomcat) e dentro desta pasta copiar sua aplicação. É claro que esta é uma técnica um tanto quanto rudimentar, o famoso copiar e colar, mas funciona. Nesta segunda parte deste artigo serão trabalhadas outras técnicas de deploy para aplicações web.

Estrutura de uma aplicação WEB

Antes de trabalhar as técnicas de deploy é interessante conhecer a estrutura de uma aplicação web, uma vez que no artigo anterior, a aplicação era apenas uma página HTML.

Uma aplicação web precisa ter um local (pasta/diretório) onde são armazenados os recursos disponibilizados pela aplicação para acesso por parte do usuário. Tenha como recursos páginas web (HTML), imagens, arquivos CSS (Cascade Style Sheet – Folhas de Estilo em Cascata), Javascripts e outros recursos a mais. Note que estes recursos o usuário pode acessar diretamente através do browser. Existem outros recursos, como dados armazenados em uma base de dados, que o usuário não pode (e nem deve) acessar diretamente.

Uma aplicação web tem ainda recursos que são executados em um ambiente exclusivo do servidor, como por exemplo, classes que acessem a base de dados com dados necessários para um determinado processamento. Estes recursos são chamados por alguns autores como recursos de tecnologia servidora. Estes recursos não podem ser acessados diretamente pelo usuário através do browser, pois precisam em certas situações de recursos que são gerenciados pelo servidor. Desta forma, é preciso que sua aplicação possua um local específico para armazenamento destes recursos.

Normalmente, uma aplicação faz uso de “outras aplicações”, também chamadas como bibliotecas que desempenham uma função específica, ou ainda, mais tecnicamente falando, frameworks. Sua aplicação pode precisar acessar dados de forma mais ágil e produtiva, imprimir relatórios ou gerar gráficos, dentre muitas outras finalidades, desta forma, não é produtivo que sua aplicação crie tudo isso do zero, sendo que existem soluções disponíveis, e, na maioria das vezes, gratuitas. Assim sendo, é preciso que a aplicação armazene estes recursos em algum “local” (pasta/diretório) de sua aplicação.

Uma vez apresentado alguns dos diversos recursos possíveis para uma aplicação, a Figura 1, abaixo, apresenta a estrutura básica necessária para uma aplicação web.

Figura 1 – Estrutura básica de pastas/diretórios para uma aplicação web

Na Figura 1, a pasta WebContent representa o root de sua aplicação web. É nesta pasta que todos os recursos acessíveis de forma direta pelo seu usuário devem estar. Nela, é possível criar uma estrutura de pastas, distribuindo os arquivos de acordo a seu tipo, ou responsabilidade. A pasta WEB-INF é uma pasta que o usuário não acessa de forma direta pelo browser, o acesso é feito pelo container. A pasta lib possui recursos (bibliotecas) utilizados por sua aplicação. É comum ouvir desenvolvedores que dizem que se mais de uma aplicação utiliza uma mesma biblioteca, esta deve ser colocada na pasta de bibliotecas comuns do container. Não faça isso, pois podem acontecer sérios problemas relacionados ao class loader. A pasta classes é a pasta que terá todas as classes utilizadas por seu projeto, já compiladas e na estrutura de pacotes das mesmas.

Criando um projeto no Eclipse

Na primeira parte deste artigo (http://www.linhadecodigo.com.br/Artigo.aspx?id=2002) a aplicação criada foi através do bloco de notas e a cópia foi direta. Agora, faremos uso de uma ferramenta de desenvolvimento mais conhecida na comunidade Java, o Eclipse (http://www.eclipse.org).

Para o exemplo a ser trabalhado agora, qualquer versão do Eclipse irá atender, mas se você for instalar o Eclipse agora em sua máquina, já instale o Eclipse IDE for Java EE Developers. Detalhes básicos em relação ao Eclipse não serão apresentados neste artigo, mas me coloco a disposição para auxiliar através de email.

Bem, ao optar pela criação de um projeto Java (garanta que esteja na perspectiva Java), o Eclipse exibe uma janela semelhante a apresentada pela Figura 2.

Figura 2 – Estrutura básica de pastas/diretórios para uma aplicação web

Mantenha todas as opções marcadas por padrão, de acordo à Figura 2, informando apenas o nome para seu projeto. Clique no botão Next e a tela é atualizada, de acordo a exibida pela Figura 3.

Figura 3 – Configurando a estrutura de pastas do Projeto

É preciso criar neste projeto a estrutura de uma aplicação web, discutida anteriormente. É claro que esta estrutura pode ser montada  após a criação do projeto, mas por praticidade, é interessante fazer isso neste momento. Note na guia Source que já existe um Source Folder criado (src) que já deve ser conhecido de aplicações Java. Identifique em sua janela o botão Browser, ao lado direito inferior e clique nele. É exibido uma janela conforme demonstrado na Figura 4.

Figura 4 – Criando a estrutura de arquivos para o projeto

Um projeto Java quando é criado, o Eclipse, através do template deste tipo de projeto, cria automaticamente duas pastas (fisicamente). A primeira src é a pasta onde as classes Javas (*.java) serão armazenadas. Na perspectiva Java ela aparece como Source Folder. A segunda pasta, bin, é a pasta que receberá as classes Java compiladas, ou seja, os arquivos *.class.

A idéia é que neste momento se crie a estrutura básica para o projeto web. Basta criar as pastas necessárias, clicando no botão Create New Folder. Apenas tenha certeza que ao clicar neste botão, a pasta onde a outra será criada, esteja selecionada.

Sua estrutura deverá estar semelhante ao exibido pela Figura 5.

Figura 5 – Hierarquia de pastas/diretórios a ser criada

Mantenha a pasta classes selecionada e clique no botão OK.

A idéia de manter a pasta classes selecionada é apenas com o intuito de agilizar a seleção da nova pasta destino para os arquivos compilados (*.class).

Caso você tenha clicado no botão OK sem estar com a pasta classes selecionada, não se preocupe, é possível fazer esta seleção de outra maneira, a qual será apresentada na seqüência.

Uma vez clicado no botão OK, esta janela é fechada e então é retornado para a janela apresentada anteriormente na Figura 3.

Observe, na Figura 6, a parte da janela representada pela Figura 3 responsável por informar em que pasta/diretório os arquivos compilados devem ser gravados. Observe que ao invés do caminho LinhaDeCodigo/bin agora está o caminho específico para uma aplicação web, de acordo a estrutura explicada anteriormente. A pasta bin, agora desnecessária, pode ser removida do projeto (caso ela tenha sido criada é claro).

Figura 6 – Definindo pasta para gravação dos arquivos compilados (*.class)

Implantando a aplicação web básica

Agora, seguindo o exemplo da primeira parte desta série de artigos (http://www.linhadecodigo.com.br/Artigo.aspx?id=2002) crie na pasta WebContent um arquivo HTML com o código apresentado na Listagem 1.

OLA.HTML	<html>   <head>    <title>Página com conteúdo estático</title>   </head>   <body>     Esta página tem seu conteúdo estático   </body> </html>
Listagem 1 – Código da página ola.html, com conteúdo estático

Enfim, técnicas para deploy

Bem, após toda a conceitualização sobre a estrutura para um projeto WEB (usando Java é claro) e, a criação da mesma com uma simples página HTML, resta apresentar algumas técnicas para distribuição desta aplicação. Note que, para este exemplo básico, nada será inserido nas pastas lib e classes, pois elas serão utilizadas em artigos futuros.

A primeira técnica para deploy da aplicação, como tratado na primeira parte desta série de artigos (http://www.linhadecodigo.com.br/Artigo.aspx?id=2002) era simplesmente criar uma pasta que representasse sua aplicação na pasta webapps do Tomcat e nela copiar os arquivos de sua aplicação.

Bem, a técnica do copiar e colar ainda pode ser utilizada, mesmo com toda a estrutura que foi aqui apresentada. No artigo anterior, havia apenas um HTML, agora, há, além do HTML, pastas. Sendo assim, basta criar a pasta que represente sua aplicação no webapps e nela copiar tudo que você tem em seu projeto dentro da pasta WebContent. Tudo, quer dizer, arquivos e pastas. Sua aplicação está disponível para ser atendida pelo TomCat.

Criando um WAR – Web Application aRchive

Um arquivo WAR é um arquivo JAR (Java ARchive) salvo com uma extensão diferente. Arquivos deste tipo possuem dentro dele, normalmente, toda a estrutura e arquivos relacionados a uma aplicação web, quer sejam: páginas HTML, JSP, Servlets, imagens, bibliotecas ou qualquer arquivo necessário por sua aplicação.

O JDK traz dentre seus utilitários, um, específico para criação do arquivo jar. Este utilitário tem o nome JAR. Para executá-lo basta chamá-lo utilizando a sintaxe abaixo:

jar –cvf <nome_arquivo_war_a_ser_criado> <caminho_base_aplicação_web>

Para facilitar, acesse, através do console a pasta WebContent de sua aplicação e nela digite a seguinte instrução:

jar –cvf deploywar.war .

Se a instrução foi informada de maneira correta, sua janela deve estar semelhante a apresentada pela Figura 7.

Figura 7 – Criação de um arquivo WAR

Em sua pasta WebContent existe agora um arquivo deploywar.war. Note que não é uma boa prática ter dentro da área de recursos web o arquivo de sua aplicação. Seria mais interessante você ter criado este arquivo em outra pasta. Recomenda-se a criação de uma pasta war no mesmo nível da pasta src e nesta pasta gerar o arquivo war.

Para realizar o deploy de sua aplicação agora, basta copiar (isso mesmo) o arquivo war para a pasta webapps do Tomcat. O Tomcat verificará a existência de um novo arquivo de aplicação web em seu diretório de aplicações. Se não existir uma aplicação com o nome deste arquivo (lembre-se que uma aplicação é o nome da pasta dela – contexto) o Tomcat então descompactará este arquivo em uma pasta com seu mesmo nome. Caso isso não ocorra de imediato (pode demorar um pouco), pare o Tomcat e inicialize-o novamente. A Figura 8 apresenta a pasta webapps já com o arquivo war e a aplicação distribuída.

Figura 8 – Aplicação distribuída através de arquivo WAR

Se você acompanhar o log oferecido pelo Tomcat, poderá notar o momento em que ele descobre o arquivo war e realiza o deploy de seu site. Os arquivos de log estão em uma pasta chamada logs na instalação de seu Tomcat. Encontre o arquivo chamado catalina.<sua_data>, em meu caso catalina.2008-10-03.log. Veja a Figura 9.

Figura 9 – Log de inicialização do Tomcat

Utilizando a aplicação Manager do Tomcat para deploy e undeploy

Uma outra técnica para distribuição de uma aplicação web para o Tomcat e retirada do mesmo, é através do Manager Site Applications, oferecida pelo Tomcat. Tenha certeza que seu Tomcat esteja iniciado e acesse-o (http://localhost:8084). Sua tela deverá estar semelhante a apresentada na Figura 10.

Figura 10 – Acessando o Tomcat Manager Site

Observe, no Box Administration, a existência de um link chamado Tomcat Manager. Acesse-o e você será direcionado para a aplicação de gerenciamento e administração de sites oferecida pelo Tomcat. Como o acesso a esta aplicação precisa ser de forma autenticada, será solicitado à você um nome de usuário e senha. Caso você não o tenha, ou não se lembre, na pasta conf, de sua instalação Tomcat, existe um arquivo chamado tomcat-users.xml. Abra este arquivo. Garanta que ele esteja semelhante ao exibido pela Figura 11. Note que é definido um papel chamado manager e um usuário chamado VisualBooks, e a este usuário é atribuído o papel manager.

Figura 11 – Lista de papéis e usuários para acesso ao Tomcat Manager

Enfim, ao acessar o Tomcat Manager e ter o acesso liberado, o browser será direcionado para a aplicação, como pode ser visto pela Figura 12. Note que através desta página, são exibidas todas as aplicações disponíveis para acesso no servidor em questão, assim como a configuração de tempo máximo de inatividade (para controle de sessão) de cada aplicação. O padrão é trinta minutos.

Figura 12 – Visualizando as aplicações disponíveis no Tomcat

É possível também verificar na Figura 12 que na mesma linha de cada aplicação existe uma série de operacionalidades disponibilizadas para cada aplicação: Start, Stop, Reload e Undeploy. Como o nome de cada operação já descreve sua funcionalidade, torna-se desnecessário detalhá-las aqui, mas fica o incentivo para testes.

Ainda, ao final desta página é exibida uma área restrita para deploy, como pode ser verificado pela Figura 13.

Figura 13 – Área de deploy através do Tomcat Manager

Na área WAR file to deploy, procure por seu arquivo WAR e em seguida clique no botão deploy. Sua aplicação será então distribuída e tornada disponível para acesso.

Utilizando o ANT para processo de empacotamento e deploy de uma aplicação web

Como visto na técnica anterior, o desenvolvimento e estruturação do projeto com o Eclipse e a geração de um arquivo para distribuição, e também, o uso da distribuição através do próprio Tomcat, traz um grande benefício, mas, ainda traz muito trabalho “braçal”. Seria muito importante que a compilação, geração do arquivo war e deploy da aplicação fosse de maneira automatizada. Até porque, se através do apresentado anteriormente, for preciso fazer o deploy duas vezes da mesma aplicação (e vários serão feitos no período de implementação), a partir do segundo deploy seria preciso antes um undeploy.

Esta técnica é possível através do uso do ANT (http://en.wikipedia.org/wiki/Apache_Ant). Detalhes acerca do ANT estão fora do escopo desta série de artigos, porém, o ANT trabalha avaliando e executando um arquivo XML, o qual define atividades e variáveis para que todo o processo de deploy de uma aplicação possa ser realizado. Por convenção, o arquivo a ser utilizado pelo ANT é nomeado build.xml.

Pode-se avaliar o arquivo build.xml como um arquivo que fornece informações para processamento pelo ANT. Em nosso caso, precisamos que haja uma compilação, que seja possível criar arquivo war, para que o mesmo possa ser distribuído e que haja a possibilidade de, antes de ser realizado o deploy do war, a aplicação, caso exista, ser retirada do servidor (undeploy). Desta forma pode-se identificar uma situação necessária: como conectar com o Tomcat? Para resolver este problema, arquivos de propriedades são criados, os quais terão configurações (informações) que subsidiem o arquivo build.xml para propiciar ao ANT a conexão com o Tomcat.

Para criação dos arquivos que contenham estas informações, por organização, crie uma pasta chamada ANT e dentro dela crie três arquivos: ant.properties, tomcat-task.properties e tomcat.properties. Veja a estrutura na Figura 14.

Figura 14–Estrutura para armazenamento dos arquivos de propriedades para uso no build.xml

O primeiro arquivo, ant.properties, é responsável apenas por informar o nome da aplicação, e seu conteúdo pode ser verificado Listagem 2.

webapp.name=linhadecodigo

Listagem 2 – Definição do nome da aplicação no arquivo ant.properties

O segundo arquivo a ser apresentado é o tomcat.properties. Este arquivo é responsável em manter informações para conexão com o Tomcat, para que, os deploys e undeploys automatizados possam ocorrer.

tomcat.server=localhost tomcat.manager.url=http://${tomcat.server}:8084/manager tomcat.username=VisualBooks tomcat.password=utfpr

Listagem 3 – Definição de valores para a conexão com o Tomcat

Observe na primeira linha a definição do endereço do Tomcat e, na segunda linha, é possível verificar o uso desta variável, através do uso de Expression Language, o que certamente trataremos em novos artigos, e também em meu livro sobre desenvolvimento web que será publicado em 2009. Veja também que a segunda linha aponta para a URL que utilizamos para deploy de uma aplicação diretamente pelo Tomcat.

O terceiro e último arquivo referente à configuração para acesso a Tomcat através do ANT, tomcat-task.properties, possui o nome das classes responsáveis pelo Deploy e Undeploy, como pode ser verificado na Listagem 4.

undeploy=org.apache.catalina.ant.UndeployTask deploy=org.apache.catalina.ant.DeployTask

Listagem 4 – Definição das classes responsáveis pelo Deploy e Undeploy

Antes de apresentar o conteúdo do arquivo build.xml, vamos verificar como habilitar a visualização ant no Eclipse. Para isso, basta acessar o menu Windows → Show → View Ant, como mostra a Figura 15.

Em seguida, é exibida no ambiente a Visão do Ant, como pode ser verificado pela Figura 16.

No mesmo nível da pasta ant, crie um arquivo chamado build.xml e arraste-o para a visão do ANT.

Figura 15–Habilitando a Visão ANT

Figura 16–Visão do ANT habilitada

O conteúdo do arquivo build.xml será apresentado e comentado em partes, uma vez que ele possui cerca de setenta linhas e fica inviável exibi-lo de uma única vez. A Figura 17 apresenta esta primeira parte. Note que a linha 1 define o elemento raiz (root) do XML. Nesta linha é definido o nome do projeto, assim como a atividade que deverá ser executada por padrão pelo ANT. Existe forma de executar qualquer atividade e não apenas a padrão. As linhas 3 e 4 importam para o contexto do arquivo build.xml as informações de dois dos arquivos apresentados anteriormente. O conteúdo entre as linhas 6 e 10 definem uma tarefa e informam o caminho físico do JAR (biblioteca) necessário para a execução das classes definidas no respectivo arquivo, também apresentado anteriormente.

Figura 17–Primeira parte da apresentação do arquivo build.xml

A Figura 18 define a atividade responsável pela compilação de seu projeto. Pode-se pensar: “Mas o eclipse já não processa a compilação?”. Sim, é fato, mas o ANT não é executado apenas pelo Eclipse, é possível executar o build.xml através da linha de comando por exemplo. Observe que a linha 16 cria uma estrutura de pastas, no mesmo nível onde está seu arquivo build.xml. A linha 17 define onde estão os arquivos a serem compilados, e a linha 18, define onde os arquivos compilados serão armazenados.

Figura 18–Definição da atividade de compilação

A Figura 19 define a atividade responsável pela geração do arquivo war. Observe a existência do elemento depends. Este elemento expressa que, antes de executar a atividade gerar-war o ANT deverá executar a atividade compilar e limpar. As linhas 26 e 27 têm o mesmo significado do explicado na atividade compilar. As instruções entre as linhas 29 e 36, definem uma atividade de cópia de arquivos. O elemento todir define o destino, fileset define o diretório base e os elementos include definem máscaras para os arquivos que devem ser copiados. Terminando esta atividade, resta a linha 38, responsável pela geração do arquivo war. Observer o uso de Expression Language para obter o nome da aplicação, que dará nome ao arquivo.

Figura 19–Definição da atividade de gerar-war

A Figura 20 apresenta a definição da atividade undeploy, responsável por retirar uma aplicação “do ar”. Veja o uso de Expression Language no código existente entre as linhas 42 e 45. Note que esta atividade, assim como a de deploy não precisa que o Tomcat seja parado (interrompido).

Figura 20–Definição da atividade de undeploy

A Figura 21 traz a definição da atividade deploy. Nesta atividade, o único elemento ainda não trabalhado está n alinha 54, que define o arquivo war que será disponibilizado no Tomcat. Note, que antes da execução do deploy, o undeploy e o gerar-war são executados.

Figura 21–Definição da atividade de deploy

A Figura 22 apresenta as duas últimas atividades definidas neste arquivo build.xml. Elas são responsáveis pelo processo de limpeza e remoção dos arquivos gerados pelo processo de compilação e build.

Figura 22–Definição das atividades responsáveis pela limpeza

A Figura 23 apresenta o arquivo build.xml de forma expandida, apresentando suas atividades.

Para executar qualquer atividade, basta dar um duplo-clique sobre ela, ou clicando com o botão direito do mouse sobre a atividade desejada e optando por executar a mesma através do ANT.

Note a atividade gerar-war, marcada como default (padrão). Isso significa que se o duplo-clique for no arquivo, é esta atividade que deve ser executada.

É possível ainda optar pela execução da atividade deploy, pois ela já faz o undeploy, gera o war e em seguinda realiza o deploy.

Figura 23–Visão do ANT com build.xml e suas atividades

Para testar esta técnica de deploy, inicialize o Tomcat e execute a atividade deploy. O resultado deve ser semelhante ao exibido na Figura 24. Observe a falha em vermelho na execução da atividade undeploy. Esta falha se deve ao fato de ser a primeira vez em que o deploy é realizado, desta forma, a aplicação ainda não está disponível para que possa ser retirada de serviço.

Figura 24–Resultado da execução do deploy através do ANT

Bem, com isto posto, concluímos esta nova parte desta série de artigos. Esta técnica de deploy com ANT foi retirada do livro Pro JSP 2, da Apress (www.apress.com), o qual recomendo fortemente.

Reforço que para qualquer dúvida ou problema que surja, estarei a disposição através de meu email.