JavaRush /Blogue Java /Random-PT /Sem pathos. Vamos falar sobre Java EE, servlets e seus co...
eGarmin
Nível 41

Sem pathos. Vamos falar sobre Java EE, servlets e seus containers

Publicado no grupo Random-PT
Neste tópico, gostaria de falar francamente sobre minha compreensão de servlets, o que são contêineres de servlet, o que são a maioria, senão todas, as estruturas de front-end da web e também abordar o tópico de como os contêineres de servlet e os servidores de aplicativos se relacionam com entre si e contêineres de servlet e servidor web. Sem pathos.  Vamos falar sobre Java EE, servlets e seus containers – 1Antes de iniciar a conversa, quero ressaltar que realmente espero que haja uma discussão, porque... Aqui não quero fornecer um único trecho de código, mas apenas tocar na essência, que sempre pode ser expressa em palavras. Tentarei delinear todos os pontos que não estavam claros para mim quando comecei. Quando fiz perguntas em vários fóruns sobre como o contêiner de servlet Tomcat difere de qualquer servidor de aplicativos, digamos WebSphere ou Geronimo, as únicas pessoas que ousaram responder foram idiotas que não conseguiam dizer nada além de “olhe para a Wikipedia” ou “ é difícil dizer, aplicativos de servidor - esta é uma infraestrutura complexa para aplicativos corporativos, que..." blá, blá, blá. Não suporto pessoas assim e acho que a maioria de vocês também não. Corrigiremos a injustiça histórica. Ir…

Servlets

Não importa o que digam, um servlet é uma página web escrita em Java. Alguns dirão que estou errado e que servlet é uma aplicação web e que existe uma diferença nesses conceitos, mas não é assim. Agora não há diferença, e sites escritos em PHP também podem ser chamados com segurança de aplicativos da web. Agora isso é completamente natural, porque... php suporta totalmente OOP, e CMSs como Joomla usam isso ativamente. O que é um servlet no nível do código? Esta é uma classe que possui vários métodos que dormem e verificam se alguém os acessa por meio de solicitações GET ou POST HTTP. Aqueles. Digitamos alguma solicitação GET no navegador, o método correspondente da classe servlet a aceita e então gera uma resposta na forma de uma página HTML. No sentido clássico de servlet, tal como foi concebido pela Sun, esta página era enviada ao cliente linha por linha, começando com a linha <!DOCTYPE htm>> e terminando com a linha </html>. Portanto, em Java existe uma classe básica de servlet chamada Servlet. Além disso, há várias outras classes que herdam dessa classe base e, assim, estendem sua funcionalidade. Isso é o que é um servlet – nada mais. É apenas um análogo Java do código PHP, que também é executado no servidor, e apenas a resposta à solicitação do navegador na forma de uma página da web é enviada ao cliente. Todos.

Estruturas de front-end da Web

O subtítulo é complicado e geralmente eles escrevem apenas framework front-end ou mesmo web muzzle , mas resolvi enfatizar aqui que quando falamos de frameworks front-end, estamos falando de uma GUI para trabalhar com Java através de um navegador web. Aqueles. aqui novamente estamos falando de sites em Java, ou seja, sobre servlets. O que é quase qualquer framework front-end, por exemplo, Apache Struts. É simplesmente um conjunto de classes que estendem a classe base Servlet. Nada mais. Aqueles. é apenas uma maneira diferente de criar o mesmo servlet regular. Acontece que os desenvolvedores deste framework (ou em outras palavras, os desenvolvedores desta tecnologia) consideraram que a adição da classe base Servletcom alguns métodos seria mais conveniente para o programador do que a escassa funcionalidade que o servlet clássico da Sun/Oracle tem.

Páginas JSP

Quase imediatamente, outra ideia veio à mente dos desenvolvedores do conceito de servlet Java. Como estamos escrevendo um servlet, cuja tarefa é enviar uma página html ao cliente, então talvez seja mais correto escrever imediatamente esta página html, e se você precisar de algum tipo de lógica em Java, basta inseri-la diretamente no html. Se não ficar mais claro, a frase pode ajudar: uma página jsp é análoga a uma página php. Difícil? Depois explico novamente. O que fazemos ao escrever uma página em PHP? Temos html estático, e quando precisamos inserir alguma lógica no PHP como loops e condições, inserimos no corpo da tag <?php … ?>. Com jsp tudo é igual, apenas a lógica é escrita em Java puro, cujo código é inserido no corpo da tag <% … %>. Voltemos ao conceito de servlet mais uma vez. Em essência, uma página JSP é um servlet, mas escrita de maneira um pouco diferente. Em um servlet normal, escrevemos um método que executa alguma lógica e, com base em seus resultados, gera uma página HTML para o cliente. Só que depois de algum tempo, os desenvolvedores do servlet começaram a pensar: e se praticamente não houver lógica no método, e quase apenas ocorrer a formação de uma página html, então não seria mais fácil escrever imediatamente uma página html em qual fazer inserções Java mínimas? Bem, uma última coisa sobre as páginas jsp. Na primeira vez que tal página é acessada, ela é compilada em um servlet e então executada. As solicitações subsequentes para esta página jsp serão mais rápidas porque ele já estará compilado e só precisará ser executado.

Contêiner de servlet

Então escrevemos uma classe de servlet ou uma página JSP. Qual é o próximo? Como enviá-los para um servidor web, digamos, apache, para que ele possa enviá-los ao navegador do usuário? O servidor web só pode enviar html, e se nossa página tiver, digamos, código php, então o servidor web primeiro passa a página por um interpretador que traduz php em html, e só então o resultado é enviado ao cliente. Quase a mesma coisa acontece com os servlets - antes do envio, eles precisam ser executados para que a página HTML seja gerada, e o contêiner do servlet é exatamente o responsável pela execução dos servlets e do código da página jsp. Aqueles. Um contêiner de servlet para java é um análogo do módulo interpretador php em um servidor web. Assim, quando o usuário insere um endereço no navegador web, a solicitação é enviada ao servidor web, o servidor web entende que um servlet está sendo solicitado e passa a solicitação para o contêiner do servlet. Depois disso, o contêiner do servlet executa o servlet, envia a página HTML resultante para o servidor web, que, por sua vez, a retorna ao cliente. Um contêiner de servlet pode ser executado sozinho, ou seja, sem um servidor web? Algo como o Tomcat definitivamente pode. E se quisermos criar um site que não tenha outras páginas HTML, exceto aquelas baseadas em servlets, então um contêiner de servlet será suficiente para nós. Mas se quisermos combinar um site de servlets e, digamos, páginas PHP, teremos que instalar um servidor web. Além disso, nem todos os servidores web possuem um contêiner de servlet incluído por padrão, mas quase todos permitem que você o instale como um plugin. Portanto, se quisermos lançar nosso site em alguma hospedagem na Internet, onde o Apache provavelmente roda, teremos que perguntar ao provedor se o contêiner do servlet está conectado.

JavaEE

Existe o chamado JavaSE (Java Standard Edition). Este conceito inclui todas as classes java, para cuja utilização precisamos apenas importá-las (por exemplo, java.util.Date) ou mesmo não precisamos fazer isso (por exemplo, Stringjá que está localizado no pacote java.lang). E existe o Java EE (Java Enterprise Edition). Essas classes também pertencem à Sun/Oracle, mas a única diferença é que são mais difíceis de começar a usar em um projeto. Uma simples linha import…não será suficiente, porque... o projeto não será compilado. Para corrigir a situação, você precisará encontrar o arquivo da biblioteca javaee.jar e incluí-lo no projeto. Isso pode ser feito através das propriedades do projeto no ambiente de desenvolvimento. Costuma-se dizer que esse processo de conexão é chamado: registrar um apelido jar no caminho de construção ou caminho de classe do projeto.

Servidor de aplicativos

Agora imagine que compilamos nosso projeto de servlet que usa Java EE. Tudo está ótimo, mas agora precisamos colocar nossas classes compiladas em um contêiner de servlet. Digamos que eles fizeram isso. Nosso aplicativo funcionará? A resposta é não. Ao acessar o servlet, serão lançadas exceções indicando que algumas classes não foram encontradas. Por que? Porque “enganamos” o compilador escorregando javaee.jar в classpath, ou seja, o compilador viu que as classes do Java EE estavam instaladas e se acalmou, mas o contêiner do servlet não vê essas classes, mas vê links para elas do nosso servlet. Esta situação pode ser resolvida em um contêiner de servlet? Claro que sim, você só precisa adicionar o arquivo da biblioteca javaee.jar à pasta com nosso servlet no contêiner do servlet . Agora imagine que haverá muitos desses projetos e todos eles serão executados em um contêiner de servlet Tomcat. Isso significa que você terá que copiar este arquivo jar para a pasta de cada servlet. Isso é inconveniente e errado. A situação foi resolvida com a introdução do conceito de servidor de aplicação, no qual esse arquivo está há muito tempo em uma única cópia, e todos os servlets podem acessá-lo, e não ter sua própria cópia. Na minha opinião, é muito conveniente e lógico. Naturalmente, toda a confusão não se deve a um arquivo jar (dei-o como exemplo) - existem muitos desses arquivos. Mas isso não é tudo que os servidores de aplicativos nos oferecem. Os próprios servidores de aplicativos podem manter conexões com muitos recursos, por exemplo, um banco de dados. Nesse caso, nosso servlet pode não abrir essa conexão sozinho, mas simplesmente retirá-la do servidor de aplicativos. Em um contêiner de servlet, isso é impossível, porque... um contêiner é, até certo ponto, um servidor de aplicativos simplificado. Em um contêiner, um servlet deve sempre criar conexões com o próprio banco de dados. Algo assim... arquivo de guerra O que é um arquivo de guerra? WAR é um arquivo da web. Na verdade, é apenas um arquivo zip, como qualquer jar. Basicamente, esta é apenas uma maneira de comprimir nosso site, que consiste em muitas páginas da web, páginas jsp e classes de servlet, em um arquivo zip. web.xml web.xml é o chamado descritor de implantação. Este é um arquivo que descreve estupidamente qual solicitação de linha do navegador da web enviar para qual classe de servlet para processamento, para que o contêiner do servlet não fique confuso, qual servlet é responsável por quê. Em geral, em Java está muito na moda descrever configurações em todos os tipos de arquivos xml, mas recentemente tem havido uma tendência de se afastar dessa tradição. Como, você pergunta? E por meio de anotações. As classes de anotação em si não fazem nada; elas foram criadas apenas para descrever todos os tipos de configurações (metadados), não em um arquivo xml separado, mas diretamente no código. Muito confortavelmente. Porém, agora existe um certo estágio intermediário, quando algumas configurações são especificadas por anotações, e outras por xml, e isso pode ser confuso, porque Você olha o xml e vê uma configuração, mas de acordo com as anotações existe outra. Qual deles tem a maior prioridade? Quem sabe…

Conclusão

Tendo escrito isto, pensei que uma revisão tão rápida não ajudaria ninguém, porque... não contém detalhes e nem exemplos, mas por outro lado, não apague o que está escrito, então deixe estar.
Comentários
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION