CodeGym /Java блог /Случаен /Част 6. Контейнери за сервлети

Ниво

San Francisco

21 July 2023
176 views
0 comments

Част 6. Контейнери за сервлети

Този материал е част от поредицата "Въведение в развитието на предприятието". Предишни статии:

В миналата статия се запознахме със сървлетите и научихме How да ги използваме за създаване на уеб applications. Дойде време да разгледаме по-отблизо съществена част от това забавление: контейнери за сервлети.

Съдържание:

Какво е сервлет контейнер?

Това е програма, която работи на сървър и може да взаимодейства със сървлетите, които създадохме. С други думи, ако искаме да стартираме нашето уеб приложение на сървър, първо разполагаме сервлет контейнер и след това поставяме сервлети в него. Работният процес е прост: когато клиентът има достъп до сървъра, контейнерът обработва неговата заявка, определяйки кой сървлет трябва да я обработи, и след това предава заявката. Част 6. Контейнери за сервлети - 2

Как се използват сервлет контейнерите?

В допълнение към заявките за маршрутизиране, контейнерът за сървлети изпълнява и други функции:

Той динамично генерира HTML страници от JSP файлове.
Той криптира/декриптира HTTPS съобщения.
Той осигурява ограничен достъп за администриране на сървлети.

Като цяло всичко това звучи добре. Сега просто трябва да разберем How да приложим всичко това на практика. Е, за да научите How да използвате нещо, просто се потопете и опитайте да го използвате :) И така, днес ще практикуваме! Най-популярният сервлет контейнер е Apache Tomcat . Той е с отворен code и може да се използва безплатно. Изтеглете Tomcat за вашата операционна система тук и ние ще проучим работата с контейнери „в действие“.

Инсталиране и стартиране на Tomcat

За да инсталирате Tomcat, просто разархивирайте изтегления архив в желаната директория.
Моля, обърнете внимание, че Tomcat изисква Java version 8 or по-нова, за да стартира и работи. Проверете дали променливата на средата JAVA_HOME препраща към текущата version на JDK.
След това трябва да конфигурирате потребителски достъп до Tomcat . Това става във file tomcat-users.xml, който се намира в папката conf.

В Tomcat има четири предварително зададени роли:
- manager-gui — Достъп до графичния интерфейс и pageта за състояние
- manager-script — Достъп до текстовия интерфейс и pageта за състояние
- manager-jmx — Достъп до JMX и pageта за състояние
- manager-status — Достъп само до pageта със състоянието
Вътре в тага <tomcat-users> ние изрично посочваме тези роли и ги присвояваме на нашия потребител:
```
<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"/>
```
Сега всичко е готово за стартиране!
В папката bin стартирайте file startup.bat (startup.sh на Linux).
След няколко секунди отворете връзката http://localhost:8080/ във вашия браузър. Ще видите графично табло:

Ако видите подобно меню, Tomcat работи.
Ако не работи, проверете ръчно променливите на средата JAVA_HOME и CATALINA_HOME:
- JAVA_HOME — Това трябва да препраща към текущата version на Java 8+.
- CATALINA_BASE — Това трябва да препраща към Tomcat or да липсва (не трябва да препраща към друга version на Tomcat).

Разполагане на приложение в Tomcat

Успяхме да стартираме Tomcat, така че сега е време да внедрим няHowъв проект в него. Нека използваме сървлетите от предишната статия . 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");
   }
}

Преди да внедрим, трябва да опаковаме нашите сървлети във WAR файл. Maven обикновено се използва за това, но за да създадете WAR файл, имате нужда от файл web.xml, който има картографиране за всички сървлети. Използвахме новата анотация @WebServlet, за да напишем сървлетите, така че нямаме файл web.xml. За щастие, IDEA може да свърши мръсната работа instead of нас, като опакова нашия проект във WAR файл. За да направите това, отворете структурата на проекта (Ctrl+Shift+Alt+S) -> Артефакти -> Изберете желания WAR файл -> Поставете отметка в квадратчето до „Включване в изграждането на проекта“ -> Щракнете върху „OK“. Част 6. Контейнери за сервлети - 4

Нека изградим проекта с помощта на клавишната комбинация Ctrl+F9. Сега нашият WAR файл е в целевата директория. Част 6. Контейнери за сервлети - 5

Файлът може да бъде преименуван на нещо по-просто, напр. servlet.war, и преместен на по-удобно място, напр. C:\\my\\.ще го поставим в контейнер . Има два начина да направите това.

Използване на графичния интерфейс

За да направите това, следвайте тази връзка: http://localhost:8080/manager/html . Tomcat трябва да поиска потребителско име и парола.

Ако сте следвали заедно с мен до този момент, тогава потребителското име е "потребител", а паролата е "парола" .

След като влезете успешно, ще видите Tomcat Web Application Manager. Разделът „Приложения“ вече съдържа 5 applications — това са помощни програми на Tomcat, които улесняват работата с Tomcat. Те могат да бъдат изтрити в бъдеще.

По-долу е разделът „Внедряване“. Тук можете да изберете WAR архива за внедряване. Нека въведем ръчно пътя и контекста:

Щракнете върху „Разполагане“ и виждаме, че нашето приложение се е появило в секцията „Приложения“:
Използвайки графичния интерфейс на Tomcat, можем да спрем, рестартираме и изтрием сесия, Howто и да зададем продължителността на сесията. При внедряването ние посочихме контекста /demo, което означава, че нашето приложение е достъпно чрез http://localhost:8080/demo . Провери го. Всичко трябва да работи.
Чрез файловата система

За да разположите приложението по този начин, трябва да отворите директорията, в която Tomcat е разархивиран. След това отидете в папката "webapps". Тук ще намерите помощните програми, които вече сме срещали:

Всичко, което се изисква, е да преместим нашия файл servlet.war тук.

Изчакваме няколко секунди и след това виждаме, че се е появила нова папка "servlet". Това означава, че нашето приложение е внедрено. Отидете до интерфейса на Application Manager на http://localhost:8080/manager/ . Тук виждаме, че нашето приложение е разгърнато в /servlet контекста:

Когато се разположи по този начин, контекстът се присвоява автоматично въз основа на името на разгърнатия WAR файл. За да промените контекста, можете да преименувате новосъздадената папка, която съдържа приложението, но преди да направите това, трябва да премахнете WAR file. В противен случай Tomcat ще преразпредели приложението с името на архива.

Както можете да видите, разполагането на applications в Tomcat е много по-лесно, отколкото може да изглежда. Но другите му функции също са лесни за използване. Да проверим.

Използване на HTTPS instead of HTTP

Ако си спомняте, разгледахме разликата между HTTP и HTTPS в отделна статия . HTTPS е същият протокол като HTTP, но криптира данните, които се предават. От страна на клиента браузърът е отговорен за криптирането, но ние трябва да осигурим криптирането от страна на сървъра. Тъй като Tomcat приема и насочва HTTP заявки, има смисъл да му се делегира криптиране. За да направим това, ние трябва:

Генерирайте самоподписан сертификат
Направете допълнителни настройки на сървъра

Нека се упражним да правим това.

Генериране на сертификат

Независимо от versionта, JDK включва голям брой помощни програми. Един от тях е keytool . Това е инструмент за генериране и работа с ключове за криптиране. За да го използвате, от командния ред отидете в директорията C:\\Program Files\\Java\\jdk1.8.0_181\\bin и изпълнете командата keytool -genkey -alias tomcat -keyalg RSA .

keytool — Името на помощната програма, която изпълняваме с опции на командния ред
-genkey — Посочва, че искаме да генерираме нов ключ
-alias tomcat — Създаване на ключов псевдоним
-keyalg RSA — Изберете RSA като алгоритъм за генериране на ключ

След като изпълни командата, помощната програма започва диалог с нас: Част 6. Контейнери за сервлети - 11

Въведете необходимата информация. Сега създадохме хранorще за ключове в нашата домашна директория (за Windows това е C:\\Users\\{username}\\.keystore) и ключ tomcat в него. Генерирахме прост сертификат, от който повечето браузъри ще се оплакват. Такъв сертификат не е подходящ за търговски applications: той може да се използва само за тестови цели. На производствен сървър трябва да използвате сертификат от сертифициращ орган (например https://letsencrypt.org/ ).

Конфигуриране на сървъра

Сега, когато сертификатът е готов, трябва да коригираме настройките на сървъра, а именно SSL конектора. Това се прави във file server.xml, който се намира в apache-tomcat-9.0.30/conf/ . В него намираме блокове като този:


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

и поставяме нашата конфигурация до тях:


    <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"/>

Присвояваме най-новите стойности на параметрите keystoreFile и keystorePass, запазваме file и след това рестартираме Tomcat, като използваме файловете shutdown.bat и startup.bat. Сега сървърът е готов да обработва HTTPS заявки. Адресът се промени съвсем малко: https://localhost:8443/demo/hello . Когато щракнете върху връзката, ще получите предупреждение за надеждността на сертификата, което не е изненадващо. Както казахме малко по-рано, трябва да използвате услугите на един от сертифициращите органи, за да получите нормален сертификат. Но засега постигнахме целта си: приложението работи с HTTPS протокол и това е важно!

Динамично генериране на HTML страници

Сега ще продължим нашия преглед на сървлет контейнерите, като разгледаме друга функция: динамично генериране на HTML страници. Представете си перфектен свят, в който instead of скучен статичен HTML code можете да пишете Java code, като използвате променливи, цикли, масиви и други езикови конструкции. Успяхте ли да си го представите? Добрата новина е, че нещо подобно съществува. Лошата новина е, че не постига напълно тази фантазия. Ако не сте се досетor, говорим за JavaServer Pages (JSP). Накратко, това е технология, която ви позволява да вмъквате части от Java code в HTML page. Вярно е, че този Java code все още се преобразува в HTML, преди да бъде изпратен на клиента, но този HTML ще бъде динамично генериран, като се вземат предвид различни фактори. Например, можете да използвате условни изрази и да връщате различно съдържание в зависимост от дадено condition. Примерна JSP page:


<%@ 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>

Можете да прочетете повече за JSP тук. В края на краищата, тази статия не е за JSP — тук сме, за да говорим за сервлет контейнери! И така, защо споменахме JSP? Просто е: контейнерът на сървлет е това, което преобразува Java codeа от JSP в HTML. Когато сървлетът ще върне JSP съдържание като отговор, контейнерът взема бележка и първо го преобразува в удобна за браузър HTML page, преди да изпрати такова съдържание на клиента. Днес има много аналози на технологията JSP — Thymeleaf, FreeMarket, Mustache и други. Всички те работят по подобен начин. Кое от тях да изберете за вашата работа е въпрос на вкус. Това се отнася и за избора на контейнер за сервлети. В тези примери използвахме Tomcat, най-често срещаният контейнер, но някои проекти използват други контейнери. Струва си да прегледате накратко най-популярните и да помислите How се различават от Tomcat.

Алтернативи на Tomcat

GlassFish е контейнер с отворен code, чиято разработка се поддържа от Oracle.

За разлика от Tomcat, той е пълноценен уеб сървър, който освен със сървлети може да работи и с други компоненти от JavaEE framework. Това каза, че използва много повече RAM. Има по-голяма гъвкавост при фина настройка на сървъра, което усложнява използването му. Трябва да се използва при разработване на applications върху рамката JavaEE.
WildFly беше известен преди като JBoss . Освен това е с отворен code. Разработен е от Red Hat. Името беше променено, за да се избегне объркване с друг от продуктите на компанията - JBoss Enterprise Application Platform.

Подобно на GlassFish, WildFly е пълноценен уеб сървър. Между другото, под капака, WildFly използва Tomcat като контейнер за сървлети. За разлика от GlassFish, WildFly е по-лек и лесен за конфигуриране.
Jetty , Howто и предишните, е с отворен code. Разработен е от Eclipse.

Подобно на Tomcat, това е прост контейнер за сервлети, без поддръжка за всички компоненти на рамката JavaEE. В същото време е по-лек и дори може да се стартира на мобилен телефон. Стартира и спира бързо и мащабира добре. За разлика от Tomcat, той има по-малка общност и база от знания.
WebLogic е лицензиран софтуер, който трябва да бъде закупен преди употреба. Принадлежи на Oracle.

Има малко по-широка функционалност от Tomcat. Може да работи с FTP протокола. Но не е толкова гъвкав при разработване и тестване на applications.
WebSphere (WebSphere Application Server, за да бъдем точни) е платен софтуер. Разработен е от IBM. Подобно на WildFly и GlassFish, това е пълен сървър за applications. Но има по-удобен интерфейс за конфигуриране, плюс висока надеждност при работа.

Неговите недостатъци включват факта, че използва много ресурси и отнема много време за стартиране и спиране, което не е много удобно при разработването на малки проекти.

Изборът на правилния контейнер за сървлети or сървър за applications зависи от конкретния проект. Има проекти, при които дори явно изостанал може да се окаже отличен избор, но в началото е най-добре да направите задълбочено проучване на един сервлет контейнер. Tomcat вероятно е идеалният кандидат за това проучване. И ние вече направихме първите стъпки в изучаването му, но оттук нататък зависи от вас! В последните статии от поредицата „Въведение в развитието на предприятието“ ще се запознаем с модела MVC. Част 7. Представяне на модела MVC (Model-View-Controller).

Коментари

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION