JavaRush /Blogue Java /Random-PT /Parte 6: Contêineres de Servlets

Parte 6: Contêineres de Servlets

Publicado no grupo Random-PT
Este material faz parte da série “Introdução ao Desenvolvimento Empresarial”. Artigos anteriores: Parte 6: Contêineres de Servlets - 1No último artigo, conhecemos os servlets e aprendemos como criar aplicações web com a ajuda deles. É hora de dar uma olhada mais de perto no que este feriado não seria possível sem: contêineres de servlet.

Contente:

O que é um contêiner de servlet

Este é um programa que roda no servidor e pode interagir com os servlets que criamos. Em outras palavras, se quisermos executar nossa aplicação web em um servidor, primeiro implantamos um contêiner de servlet e depois colocamos os servlets nele. O funcionamento é simples: quando um cliente entra em contato com o servidor, o contêiner processa sua solicitação, determina qual servlet deve processá-la e repassa-a. Parte 6. Contêineres de Servlets - 2

Como usar contêineres de servlet

Além de rotear solicitações, o contêiner de servlet executa outras funções:
  1. Gera páginas HTML dinamicamente a partir de arquivos JSP.
  2. Criptografa/descriptografa mensagens HTTPS.
  3. Fornece acesso restrito para administração de servlets.
Em geral parece bom, só falta descobrir como aplicar tudo isso. Bom, para aprender a usar alguma coisa, você só precisa... tentar usar :) Então hoje vamos praticar! O contêiner de servlet mais popular é o Apache Tomcat . É de código aberto e de uso gratuito. Baixe o Tomcat para o seu sistema operacional neste link e vamos ver como trabalhar com contêineres em ação.

Instalando e executando o Tomcat

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

  2. Observe que o Tomcat requer Java versão 8 ou superior para ser executado. Certifique-se de que a variável de ambiente JAVA_HOME se refira à 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.

    O Tomcat vem pré-fornecido com quatro funções:

    • 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>, escreveremos explicitamente essas funções e as atribuiremos 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 tudo está pronto para lançar!

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

  5. Após alguns segundos, abra o link http://localhost:8080/ no seu navegador . O gerenciador gráfico aparecerá lá:

    Parte 6: Contêineres de Servlets - 3

    Se você vir esse menu, significa que o Tomcat está em execução.

  6. Caso não funcione, verifique manualmente as variáveis ​​de ambiente JAVA_HOME e CATALINA_HOME:

    • JAVA_HOME - deve referir-se à versão atual do Java 8+;
    • CATALINA_HOME - deve referir-se ao Tomcat ou estar ausente (não deve apontar para outra versão do Tomcat).

Implantando um aplicativo no Tomcat

Conseguimos lançar o Tomcat, então é hora de implantar algum tipo de projeto nele. Vamos usar os servlets do artigo anterior . Servlet Principal:
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 da implantação, nossos servlets devem ser empacotados em um arquivo war. Normalmente o Maven é usado para isso, mas para criar um arquivo war você precisa de um arquivo web.xml no qual todos os servlets são mapeados. Escrevemos servlets usando a nova anotação @WebServlet, portanto não temos web.xml. Felizmente, o IDEA pode fazer o trabalho sujo para nós e agrupar nosso projeto individualmente em um arquivo de guerra. Para fazer isso, você precisa abrir a estrutura do projeto (Ctrl + Shift + Alt + S) -> Artefatos -> Selecionar a bebida desejada -> Marque a caixa ao lado de “Incluir na construção do projeto” -> Clique em “OK”. Parte 6: Contêineres de Servlets - 4Construa um projeto usando a combinação Ctrl + F9. Agora nosso arquivo war está no diretório de destino. Parte 6: Contêineres de Servlets - 5O arquivo pode ser renomeado para algo mais simples - por exemplo, servlet.war - e movido para um local mais conveniente - em C:\my\. Quando a bebida estiver pronta para uso, coloque-a em um recipiente . Isso pode ser feito de duas maneiras.
  1. Através da interface gráfica

    Para fazer isso, siga o link http://localhost:8080/manager/html . O Tomcat deve solicitar um login e uma senha.

    Se você repetiu todas as etapas depois de mim, o login é user, a senha é password .

    Após a autorização bem-sucedida, você verá o Tomcat Web Application Manager. A seção Aplicativos já contém 5 aplicativos - esses são aplicativos utilitários do Tomcat necessários para simplificar o trabalho com ele. Eles podem ser removidos no futuro.

    Parte 6: Contêineres de Servlets - 6

    Abaixo está a seção Implantar. Usando-o, você pode selecionar um arquivo war para implantação. Vamos inserir o caminho e o contexto manualmente:

    Parte 6. Contêineres de Servlets - 7

    Clique em “Implantar”, vemos que nosso aplicativo apareceu na seção Aplicativos:

    Parte 6: Contêineres de Servlets - 8 Usando a GUI do Tomcat podemos interrompê-lo, reiniciá-lo, definir a duração da sessão e excluí-la. Ao implantar, especificamos o contexto /demo, o que significa que nossa aplicação deve ser acessada através do link http://localhost:8080/demo . Verifique, tudo deve funcionar.

  2. Através do sistema de arquivos

    Para implantar um aplicativo dessa forma, você precisa abrir o diretório no qual o Tomcat está descompactado e acessar webapps. Aqui estão os aplicativos utilitários com os quais estamos familiarizados:

    Parte 6. Contêineres de Servlets - 9

    Tudo o que precisamos fazer é mover nosso servlet.war para cá.

    Esperamos alguns segundos, vemos que uma nova pasta de servlet apareceu, o que significa que nosso aplicativo está implantado. Vamos para a interface familiar do Application Manager - http://localhost:8080/manager/ . Aqui vemos que nosso aplicativo é implantado no contexto /servlet:

    Parte 6. Contêineres de Servlets - 10

    Quando implantado desta forma, o contexto é automaticamente atribuído ao nome do arquivo war implantado. Para alterar o contexto, você pode renomear a pasta recém-criada com o aplicativo, mas antes disso você precisa excluir o arquivo: caso contrário, o Tomcat irá reimplantar 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 são fáceis de usar. Vamos checar.

Usando o protocolo HTTPS em vez de HTTP

Se você se lembra, discutimos a diferença entre HTTP e HTTPS em um artigo separado . HTTPS é o mesmo protocolo que HTTP, mas usa criptografia dos dados transferidos. No lado do cliente, a criptografia é controlada pelo navegador e devemos fornecer criptografia no lado do servidor. Como as solicitações HTTP são aceitas e roteadas pelo Tomcat, seria lógico delegar a criptografia a ele. Para fazer isso você precisa:
  1. Gere um certificado autoassinado;
  2. Faça configurações adicionais do servidor.
Vamos praticar isso.

Gerando um certificado

O JDK vem com um grande número de utilitários, independente da versão, um deles é o keytool . Esta é uma ferramenta para gerar chaves de criptografia e trabalhar com elas. Para utilizá-lo, através da linha de comando, acesse o diretório C:\Program Files\Java\jdk1.8.0_181\bin e execute o comando keytool -genkey -alias tomcat -keyalg RSA .
  • keytool - inicia o utilitário com parâmetros;
  • -genkey – indica que queremos gerar uma nova chave;
  • -alias tomcat — cria um alias de chave;
  • -keyalg RSA - selecione RSA como algoritmo de geração de chave.
Após executar o comando, o utilitário iniciará um diálogo conosco: Parte 6: Contêineres de Servlets - 11Insira as informações necessárias. Agora criamos um keystore em nosso diretório inicial (para Windows é C:\Users\{username}\.keystore) e uma chave do Tomcat nele. Geramos um certificado simples que a maioria dos navegadores aceitará. Este certificado não é adequado para aplicações comerciais: só pode ser utilizado para fins de teste. No servidor de produção, você deve usar um certificado de uma autoridade de certificação (por exemplo, https://letsencrypt.org/ ).

Configurando o servidor

Agora que o certificado está pronto, você precisa 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/ . Encontramos blocos como:
<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 ao lado deles colocamos nossa configuração:
<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 aos parâmetros keystoreFile e keystorePass os valores que são relevantes para nós, salvamos e reiniciamos o Tomcat usando os arquivos shutdown.bat e startup.bat. Agora o servidor está pronto para processar solicitações https, apenas um pouco no endereço alterado - https://localhost:8443/demo/hello . Ao clicar no link, você verá um aviso sobre o certificado ser questionável, o que não é surpreendente. Conforme descrito um pouco anteriormente, para obter um certificado normal é necessário utilizar os serviços de um dos serviços de certificação. Mas até agora atingimos nosso objetivo: o aplicativo funciona no protocolo HTTPS, e isso é o principal!

Geração dinâmica de páginas HTML

Agora vamos continuar nossa revisão de outros recursos dos contêineres de servlet - geração dinâmica de páginas HTML. Imagine um mundo ideal onde, em vez do enfadonho código HTML estático, você pudesse escrever código JAVA usando variáveis, loops, arrays e outras construções de linguagem. Você imaginou? A boa notícia é que existe algo semelhante, a má notícia é que não existe totalmente. Se você ainda não adivinhou, estamos falando da tecnologia JSP (Java Server Pages). Resumindo, esta é uma tecnologia que permite inserir pedaços de código JAVA em uma página HTML. É verdade que esse código ainda é transformado em HTML antes de ser enviado ao cliente, mas será gerado dinamicamente levando em consideração diversos fatores. Por exemplo, você pode usar construções condicionais e veicular conteúdos diferentes 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 . Na verdade... não estamos aqui para isso, mas sim pelos contêineres de servlets! O que JSP tem a ver com isso? É simples: a transformação do código JAVA de JSP em código HTML é realizada pelo contêiner do servlet. Quando um servlet está prestes a retornar conteúdo JSP como resposta, o contêiner percebe e primeiro o transforma em uma página HTML legível pelo navegador antes de enviar esse conteúdo ao cliente. Hoje existem muitos análogos da tecnologia JSP - Thymeleaf, FreeMarket, Moustache e outros. Todos eles funcionam com um princípio semelhante. Qual escolher para o trabalho é uma questão de gosto. Isso também se aplica à escolha de um contêiner de servlet. Nos exemplos utilizamos o Tomcat, o container mais comum, mas alguns projetos utilizam outros. Vale a pena se familiarizar brevemente com os mais populares e observar suas diferenças em relação ao Tomcat.

Alternativas para oTomcat

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

    Ao contrário do Tomcat, é um servidor web completo que, além dos servlets, pode operar outros componentes do framework JavaEE. Ao mesmo tempo, usa muito mais RAM. Mais flexível no ajuste fino do servidor, o que dificulta seu uso. Vale a pena usar ao desenvolver aplicativos usando a estrutura JavaEE.

  2. WildFly - anteriormente 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.

    WildFly, assim como GlassFish, é um servidor web completo. A propósito, nos bastidores 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 - semelhante aos anteriores, é open source. Desenvolvido por 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 até ser executado em um telefone celular. Ele inicia e para rapidamente e é bem dimensionado. Ao contrário do Tomcat, ele possui uma comunidade e base de conhecimento menores.

  4. WebLogic é um software licenciado que requer compra antes do uso. Propriedade da Oracle.

    Comparado ao Tomcat, sua funcionalidade é um pouco mais ampla. 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 mais 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 operacional.

    A desvantagem é que utiliza muitos recursos, demora muito para iniciar e parar, o que não é muito conveniente no desenvolvimento de pequenos projetos.

Qual contêiner de servlet ou servidor de aplicativos escolher depende do projeto específico. Existem projetos em que até mesmo um estranho óbvio será capaz de provar seu valor da mais alta qualidade, mas a princípio é melhor entender uma coisa completamente. Provavelmente o candidato ideal para este é o Tomcat. Já demos os primeiros passos para estudá-lo e então é com você! Nos artigos finais da série “Introdução ao Desenvolvimento Empresarial”, conheceremos o padrão MVC. Parte 7. Introdução ao padrão MVC (Model-View-Controller) Parte 8. Escrevendo uma pequena aplicação em spring-boot
Comentários
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION