Parte 6. Contêineres de Servlets

Este material faz parte da série "Introdução ao Desenvolvimento Corporativo". Artigos anteriores:

• sobre networking
• sobre arquitetura de software
• sobre HTTP/HTTPS
• sobre o básico do Maven
• sobre servlets (escrever uma aplicação web simples)

No último artigo, nos familiarizamos com os servlets e aprendemos como usá-los para criar aplicativos da web. Chegou a hora de dar uma olhada em uma parte essencial dessa diversão: os contêineres de servlet.

Índice:

• O que é um contêiner de servlet?
• Como os contêineres de servlet são usados?
• Instalando e iniciando o Tomcat
• Implantando um aplicativo no Tomcat
• Usando HTTPS em vez de HTTP
• Gerando um certificado
• Configurando o servidor
• Gerando páginas HTML dinamicamente
• Alternativas ao Tomcat

O que é um contêiner de servlet?

É um programa que roda em um servidor e pode interagir com os servlets que criamos. Em outras palavras, se quisermos executar nosso aplicativo da Web em um servidor, primeiro implantamos um contêiner de servlet e, em seguida, colocamos servlets nele. O fluxo de trabalho é simples: quando o cliente acessa o servidor, o contêiner processa sua solicitação, determinando qual servlet deve processá-la e, então, repassa a solicitação.

Como os contêineres de servlet são usados?

Além de rotear solicitações, um contêiner de servlet executa outras funções:

1. Ele gera dinamicamente páginas HTML a partir de arquivos JSP.
2. Ele criptografa/descriptografa mensagens HTTPS.
3. Ele fornece acesso restrito para administração de servlet.

Em geral, tudo isso soa bem. Agora só precisamos descobrir como colocar tudo isso em prática. Bem, para aprender a usar algo, basta mergulhar e tentar usá-lo :) Então, hoje vamos praticar! O contêiner de servlet mais popular é o Apache Tomcat . É de código aberto e pode ser usado gratuitamente. Baixe o Tomcat para seu sistema operacional aqui e exploraremos o trabalho com contêineres "em ação".

Instalando e iniciando o Tomcat

1. Para instalar o Tomcat, basta descompactar o arquivo baixado no diretório desejado.

2. Observe que o Tomcat requer o Java versão 8 ou superior para iniciar e executar. Verifique se a variável de ambiente JAVA_HOME faz referência à versão atual do JDK.

3. Em seguida, você precisa configurar o acesso do usuário ao Tomcat . Isso é feito no arquivo tomcat-users.xml, localizado na pasta conf.

   Existem quatro funções predefinidas no Tomcat:

   • manager-gui — Acesso à interface gráfica e página de status
   • manager-script — Acesso à interface de texto e à página de status
   • manager-jmx — Acesso ao JMX e à página de status
   • manager-status — Acesso apenas à página de status

   Dentro da tag <tomcat-users>, especificamos explicitamente essas funções e as atribuímos ao nosso usuário:

   
   <role rolename="manager-gui"/>
   <role rolename="manager-script"/>
   <role rolename="manager-jmx"/>
   <role rolename="manager-status"/>
   <user username="user" password="password"
       roles="manager-gui, manager-script, manager-jmx, manager-status"/>
   

   Agora está tudo pronto para o lançamento!

4. Na pasta bin, execute o arquivo startup.bat (startup.sh no Linux).

5. Após alguns segundos, abra o link http://localhost:8080/ em seu navegador. Você verá um painel gráfico:

   Se você vir um menu como este, o Tomcat está em execução.

6. Se não estiver em execução, verifique manualmente as variáveis ​​de ambiente JAVA_HOME e CATALINA_HOME:

   • JAVA_HOME — Deve fazer referência à versão atual do Java 8+.
   • CATALINA_BASE — Deve fazer referência ao Tomcat ou estar ausente (não deve fazer referência a outra versão do Tomcat).

Implantando um aplicativo no Tomcat

Conseguimos lançar o Tomcat, então agora é hora de implantar algum projeto nele. Vamos usar os servlets do artigo anterior . MainServlet:

import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import java.io.IOException;
import java.io.PrintWriter;

@WebServlet("/hello")
public class MainServlet extends HttpServlet {

   @Override
   protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
       HttpSession session = req.getSession();
       Integer visitCounter = (Integer) session.getAttribute("visitCounter");
       if (visitCounter == null) {
           visitCounter = 1;
       } else {
           visitCounter++;
       }
       session.setAttribute("visitCounter", visitCounter);
       String username = req.getParameter("username");
       resp.setContentType("text/html");
       PrintWriter printWriter = resp.getWriter();
       if (username == null) {
           printWriter.write("Hello, Anonymous" + "
");
       } else {
           printWriter.write("Hello, " + username + "
");
       }
       printWriter.write("Page was visited " + visitCounter + " times.");
       printWriter.close();
   }
}

IndexServlet:

import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@WebServlet("/")
public class IndexServlet extends HttpServlet {

   @Override
   protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
       resp.sendRedirect(req.getContextPath() + "/hello");
   }
}

Antes de implantar, precisamos empacotar nossos servlets em um arquivo WAR. O Maven geralmente é usado para fazer isso, mas para criar um arquivo WAR você precisa de um arquivo web.xml que tenha um mapeamento para todos os servlets. Usamos a nova anotação @WebServlet para escrever os servlets, então não temos um arquivo web.xml. Felizmente, o IDEA pode fazer o trabalho sujo para nós, envolvendo nosso projeto em um arquivo WAR. Para fazer isso, abra a estrutura do projeto (Ctrl+Shift+Alt+S) -> Artefatos -> Selecione o arquivo WAR desejado -> Marque a caixa de seleção ao lado de "Incluir na compilação do projeto" -> Clique em "OK". Vamos construir o projeto usando a combinação de teclas Ctrl+F9. Agora nosso arquivo WAR está no diretório de destino. O arquivo pode ser renomeado para algo mais simples, por exemplo, servlet.war, e movido para um local mais conveniente, por exemplo, C:\\my\\.vamos colocá-lo em um recipiente . Existem duas maneiras de fazer isso.

1. Usando a interface gráfica

   Para fazer isso, siga este link: http://localhost:8080/manager/html . O Tomcat deve solicitar um nome de usuário e senha.

   Se você me acompanhou até este ponto, o nome de usuário é "user" e a senha é "password" .

   Depois de entrar com sucesso, você verá o Tomcat Web Application Manager. A seção "Aplicativos" já contém 5 aplicativos — são utilitários do Tomcat, que facilitam o trabalho com o Tomcat. Eles podem ser excluídos no futuro.

   Abaixo está a seção "Implantar". Aqui você pode selecionar o arquivo WAR para implantar. Vamos inserir o caminho e o contexto manualmente:

   Clique em "Deploy" e vemos que nosso aplicativo apareceu na seção "Applications":

   Usando a interface gráfica do Tomcat, podemos parar, reiniciar e excluir uma sessão, bem como definir a duração da sessão. Ao implantar, especificamos o contexto /demo, o que significa que nosso aplicativo é acessado usando http://localhost:8080/demo . Confira. Tudo deve funcionar.

2. Através do sistema de arquivos

   Para implantar o aplicativo dessa forma, você precisa abrir o diretório onde o Tomcat foi descompactado. Em seguida, vá para a pasta "webapps". Aqui você encontrará os utilitários que já encontramos:

   Tudo o que é necessário é movermos nosso arquivo servlet.war para cá.

   Esperamos alguns segundos e então vemos que uma nova pasta "servlet" apareceu. Isso significa que nosso aplicativo está implantado. Acesse a interface do Application Manager em http://localhost:8080/manager/ . Aqui vemos que nosso aplicativo é implantado no contexto /servlet:

   Quando implementado dessa maneira, o contexto é atribuído automaticamente com base no nome do arquivo WAR implementado. Para alterar o contexto, você pode renomear a pasta recém-criada que contém o aplicativo, mas antes de fazer isso você precisa remover o arquivo WAR. Caso contrário, o Tomcat reimplementará o aplicativo com o nome do arquivo.

   Como você pode ver, implantar aplicativos no Tomcat é muito mais fácil do que parece. Mas suas outras funções também são fáceis de usar. Vamos checar.

Usando HTTPS em vez de HTTP

Se você se lembra, vimos a diferença entre HTTP e HTTPS em um artigo separado . HTTPS é o mesmo protocolo que HTTP, mas criptografa os dados que estão sendo transmitidos. No lado do cliente, o navegador é responsável pela criptografia, mas devemos fornecer a criptografia no lado do servidor. Como o Tomcat aceita e roteia solicitações HTTP, faz sentido delegar criptografia a ele. Para fazer isso, devemos:

1. Gerar um certificado autoassinado
2. Faça configurações adicionais do servidor

Vamos praticar fazendo isso.

Gerando um certificado

Independentemente da versão, o JDK inclui um grande número de utilitários. Um deles é o keytool . Esta é uma ferramenta para gerar e trabalhar com chaves de criptografia. Para usá-lo, na linha de comando, vá para o diretório C:\\Program Files\\Java\\jdk1.8.0_181\\bin e execute o comando keytool -genkey -alias tomcat -keyalg RSA .

• keytool — O nome do utilitário que estamos executando com opções de linha de comando
• -genkey — Indica que queremos gerar uma nova chave
• -alias tomcat — Cria um alias de chave
• -keyalg RSA — Selecione RSA como o algoritmo de geração de chave

Depois de executar o comando, o utilitário inicia um diálogo conosco: Digite as informações necessárias. Agora criamos um keystore em nosso diretório inicial (para Windows, é C:\\Users\\{username}\\.keystore) e uma chave tomcat nele. Geramos um certificado simples do qual a maioria dos navegadores reclamará. Tal certificado não é adequado para aplicações comerciais: ele só pode ser usado para fins de teste. Em um servidor de produção, você precisa usar um certificado de uma autoridade de certificação (por exemplo, https://letsencrypt.org/ ).

Configurando o servidor

Agora que o certificado está pronto, precisamos ajustar as configurações do servidor, ou seja, o conector SSL. Isso é feito no arquivo server.xml, localizado em apache-tomcat-9.0.30/conf/ . Nele, encontramos blocos como este:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="150" SSLEnabled="true">
        <SSLHostConfig>
            <Certificate certificateKeystoreFile="conf/localhost-rsa.jks"
                         type="RSA" />
        </SSLHostConfig>
 </Connector>

e colocamos nossa configuração ao lado deles:

    <Connector
           protocol="org.apache.coyote.http11.Http11NioProtocol"
           port="8443" maxThreads="200"
           scheme="https" secure="true" SSLEnabled="true"
           keystoreFile="C:\Users\user\.keystore" keystorePass="mypass"
           clientAuth="false" sslProtocol="TLS"/>

Atribuímos os valores mais recentes aos parâmetros keystoreFile e keystorePass, salvamos o arquivo e reiniciamos o Tomcat usando os arquivos shutdown.bat e startup.bat. Agora o servidor está pronto para processar solicitações HTTPS. O endereço mudou um pouco: https://localhost:8443/demo/hello . Ao clicar no link, você receberá um aviso sobre a confiabilidade do certificado, o que não é surpreendente. Como dissemos um pouco antes, você precisa usar os serviços de uma das autoridades de certificação para obter um certificado normal. Mas, por enquanto, atingimos nosso objetivo: o aplicativo é executado usando o protocolo HTTPS, e isso é importante!

Gerando páginas HTML dinamicamente

Agora continuaremos nossa visão geral dos contêineres de servlet considerando outro recurso: geração dinâmica de páginas HTML. Imagine um mundo perfeito onde, em vez de código HTML estático chato, você poderia escrever código Java, usando variáveis, loops, arrays e outras construções de linguagem. Você foi capaz de imaginar? A boa notícia é que existe algo semelhante. A má notícia é que não realiza totalmente essa fantasia. Se você ainda não adivinhou, estamos falando de JavaServer Pages (JSP). Resumindo, essa é uma tecnologia que permite inserir trechos de código Java em uma página HTML. É verdade que esse código Java ainda é convertido em HTML antes de ser enviado ao cliente, mas esse HTML será gerado dinamicamente, levando em consideração vários fatores. Por exemplo, você pode usar instruções condicionais e retornar conteúdo diferente dependendo de alguma condição. Exemplo de página JSP:

<%@ page language="java"" %>
<html>
<head>
<title>JSP</title>
</head>

<body>
<%
String firstName="name";
String secondName="surname";
    
    if (firstName.equals("name")){
      out.print("Hello: "+firstName+"<br>");
    }

    if (firstName.equals("name") && secondName.equals("surname"))
    {
      out.print("Hello, my dear friend! <br>");
    }
    else
    {
      out.print("I don't know you. Go away! <br>");
    }
%>
</body>
</html>

Você pode ler mais sobre JSP aqui. No final das contas, este artigo não é sobre JSP — estamos aqui para falar sobre contêineres de servlet! Então, por que mencionamos JSP? É simples: um contêiner de servlet é o que converte o código Java de JSP para HTML. Quando um servlet vai retornar o conteúdo JSP como resposta, o contêiner toma nota e primeiro o converte em uma página HTML amigável ao navegador antes de enviar esse conteúdo ao cliente. Hoje, existem muitos análogos à tecnologia JSP — Thymeleaf, FreeMarket, Mustache e outros. Todos eles funcionam de maneira semelhante. Qual deles escolher para o seu trabalho é uma questão de gosto. Isso também se aplica à escolha de um contêiner de servlet. Nesses exemplos, usamos o Tomcat, o container mais comum, mas alguns projetos usam outros containers. Vale a pena revisar brevemente os mais populares e considerar como eles diferem do Tomcat.

Alternativas ao Tomcat

1. GlassFish é um contêiner de código aberto cujo desenvolvimento é suportado pela Oracle.

   Ao contrário do Tomcat, é um servidor web completo que, além dos servlets, pode operar com outros componentes da estrutura JavaEE. Dito isto, ele usa muito mais RAM. Há maior flexibilidade no ajuste fino do servidor, o que dificulta seu uso. Ele deve ser usado ao desenvolver aplicativos na estrutura JavaEE.

2. WildFly era anteriormente conhecido como JBoss . Também é de código aberto. É desenvolvido pela Red Hat. O nome foi alterado para evitar confusão com outro produto da empresa — JBoss Enterprise Application Platform.

   Assim como o GlassFish, o WildFly é um servidor web completo. A propósito, sob o capô, o WildFly usa o Tomcat como um contêiner de servlet. Ao contrário do GlassFish, o WildFly é mais leve e fácil de configurar.

3. Jetty , como os anteriores, é de código aberto. É desenvolvido pela Eclipse.

   Assim como o Tomcat, é um contêiner de servlet simples, sem suporte para todos os componentes do framework JavaEE. Ao mesmo tempo, é mais leve e pode ser executado até mesmo em um telefone celular. Ele começa e para rapidamente e escala bem. Ao contrário do Tomcat, ele possui uma comunidade e uma base de conhecimento menores.

4. O WebLogic é um software licenciado que deve ser adquirido antes do uso. Pertence à Oráculo.

   Ele tem uma funcionalidade um pouco mais ampla que o Tomcat. Pode trabalhar com o protocolo FTP. Mas não é tão flexível ao desenvolver e testar aplicativos.

5. WebSphere (WebSphere Application Server, para ser preciso) é um software pago. É desenvolvido pela IBM. Semelhante ao WildFly e GlassFish, é um servidor de aplicativos completo. Mas possui uma interface de configuração mais amigável, além de alta confiabilidade na operação.

   Suas deficiências incluem o fato de consumir muitos recursos e demorar muito para iniciar e parar, o que não é muito conveniente no desenvolvimento de pequenos projetos.

A escolha do contêiner de servlet ou servidor de aplicativos correto depende do projeto específico. Existem projetos em que mesmo um azarão claro pode ser uma excelente escolha, mas primeiro é melhor fazer um estudo aprofundado de um contêiner de servlet. O Tomcat é provavelmente o candidato perfeito para este estudo. E já demos os primeiros passos para estudá-lo, mas a partir daqui é com você! Nos artigos finais da série "Introdução ao Desenvolvimento Corporativo", conheceremos o padrão MVC. Parte 7. Apresentando o padrão MVC (Model-View-Controller)