Bahagi 6: Mga Lalagyan ng Servlet

Ang materyal na ito ay bahagi ng seryeng "Introduction to Enterprise Development". Mga nakaraang artikulo:

• tungkol sa network ;
• tungkol sa arkitektura ng software ;
• tungkol sa mga protocol ng HTTP/HTTPS ;
• tungkol sa mga pangunahing kaalaman sa Maven;
• tungkol sa mga servlet (pagsusulat ng isang simpleng web application) .

Sa huling artikulo, nakilala namin ang mga servlet at natutunan namin kung paano lumikha ng mga web application sa kanilang tulong. Oras na para tingnang mabuti kung ano ang hindi magiging posible sa holiday na ito kung wala - mga servlet container.

Nilalaman:

• Ano ang isang lalagyan ng servlet
• Paano gamitin ang mga lalagyan ng servlet
• Pag-install at pagpapatakbo ng Tomcat"
• Pag-deploy ng Application sa Tomcat
• Paggamit ng HTTPS protocol sa halip na HTTP
• Pagbuo ng isang sertipiko
• Pagse-set up ng server
• Dynamic na henerasyon ng mga HTML na pahina
• Mga alternatibo sa Tomcat

Ano ang isang lalagyan ng servlet

Ito ay isang program na tumatakbo sa server at maaaring makipag-ugnayan sa mga servlet na aming ginawa. Sa madaling salita, kung gusto naming patakbuhin ang aming web application sa isang server, mag-deploy muna kami ng servlet container at pagkatapos ay ilagay ang mga servlet dito. Ang paraan ng paggana nito ay simple: kapag nakipag-ugnayan ang isang kliyente sa server, pinoproseso ng container ang kanyang kahilingan, tinutukoy kung aling servlet ang dapat magproseso nito at ipasa ito.

Paano gamitin ang mga lalagyan ng servlet

Bilang karagdagan sa mga kahilingan sa pagruruta, ang lalagyan ng servlet ay gumaganap ng iba pang mga function:

1. Dynamic na bumubuo ng mga HTML na pahina mula sa mga JSP file.
2. Nag-e-encrypt/nagde-decrypt ng mga HTTPS na mensahe.
3. Nagbibigay ng restricted access para sa servlet administration.

Sa pangkalahatan, ito ay maganda, ang natitira lamang ay upang malaman kung paano ilapat ang lahat ng ito. Well, to learn how to use something, you just need... try to use it :) Kaya ngayong araw na to magpractice tayo! Ang pinakasikat na lalagyan ng servlet ay Apache Tomcat . Ito ay open source at malayang gamitin. I-download ang Tomcat para sa iyong operating system mula sa link na ito , at tingnan natin kung paano gumawa ng mga container na gumagana.

Pag-install at pagpapatakbo ng Tomcat

1. Upang i-install ang Tomcat, i-unpack lang ang na-download na archive sa nais na direktoryo.

2. Pakitandaan na ang Tomcat ay nangangailangan ng Java version 8 o mas mataas para tumakbo. Siguraduhin na ang JAVA_HOME environment variable ay tumutukoy sa kasalukuyang bersyon ng jdk.

3. Susunod na kailangan mong i-configure ang access ng user sa Tomcat . Ginagawa ito sa tomcat-users.xml file, na matatagpuan sa conf folder.

   Ang Tomcat ay may paunang ibinigay na apat na tungkulin:

   • manager-gui - access sa graphical interface at status page;
   • manager-script - pag-access sa interface ng teksto at pahina ng katayuan;
   • manager-jmx - access sa JMX at pahina ng katayuan;
   • manager-status - access lamang sa page ng status.

   Sa loob ng tag na <tomcat-users>, tahasan naming isusulat ang mga tungkuling ito at itatalaga ang mga ito sa aming user:

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

   Ngayon ang lahat ay handa nang ilunsad!

4. Sa folder ng bin, patakbuhin ang startup.bat file (startup.sh sa Linux).

5. Pagkatapos ng ilang segundo, buksan ang link na http://localhost:8080/ sa iyong browser . Lalabas doon ang graphic manager:

   Kung makakita ka ng ganitong menu, nangangahulugan ito na tumatakbo ang Tomcat.

6. Kung hindi ito gumana, manu-manong suriin ang JAVA_HOME at CATALINA_HOME na mga variable ng kapaligiran:

   • JAVA_HOME - dapat sumangguni sa kasalukuyang bersyon ng Java 8+;
   • CATALINA_HOME - dapat sumangguni sa Tomcat o wala (hindi dapat tumuro sa ibang bersyon ng Tomcat).

Pag-deploy ng Application sa Tomcat

Nagawa naming ilunsad ang Tomcat, kaya oras na para mag-deploy ng ilang uri ng proyekto dito. Gamitin natin ang mga servlet mula sa nakaraang artikulo . 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");
   }
}

Bago i-deploy, ang aming mga servlet ay dapat na naka-package sa isang archive ng digmaan. Karaniwan ang Maven ay ginagamit para dito, ngunit upang lumikha ng isang archive ng digmaan kailangan mo ng isang web.xml file kung saan ang lahat ng mga servlet ay nakamapa. Nagsulat kami ng mga servlet gamit ang bagong @WebServlet annotation, kaya wala kaming web.xml. Sa kabutihang palad, magagawa ng IDEA ang maruming gawain para sa amin at isa-isang ibalot ang aming proyekto sa isang archive ng digmaan. Upang gawin ito, kailangan mong buksan ang istraktura ng proyekto (Ctrl + Shift + Alt + S) -> Mga Artifact -> Piliin ang nais na build -> Lagyan ng check ang kahon sa tabi ng "Isama sa pagbuo ng proyekto" -> I-click ang "OK". Bumuo ng isang proyekto gamit ang kumbinasyong Ctrl + F9. Ngayon ang aming archive ng digmaan ay nasa target na direktoryo. Ang file ay maaaring palitan ng pangalan sa isang bagay na mas simple - halimbawa, servlet.war - at inilipat sa isang mas maginhawang lugar - sa C:\my\. Kapag handa nang gamitin ang brew, ilagay ito sa isang lalagyan . Magagawa ito sa dalawang paraan.

1. Sa pamamagitan ng GUI

   Upang gawin ito, sundan ang link http://localhost:8080/manager/html . Dapat kang i-prompt ng Tomcat para sa isang login at password.

   Kung inulit mo ang lahat ng mga hakbang pagkatapos ko, ang login ay user, ang password ay password .

   Pagkatapos ng matagumpay na awtorisasyon makikita mo ang Tomcat Web Application Manager. Ang seksyon ng Mga Aplikasyon ay naglalaman na ng 5 mga aplikasyon - ito ay mga application ng Tomcat utility na kinakailangan upang pasimplehin ang pagtatrabaho dito. Maaari silang alisin sa hinaharap.

   Nasa ibaba ang seksyon ng Deploy. Gamit ito, maaari kang pumili ng archive ng digmaan para sa pag-deploy. Ipasok natin ang landas at konteksto nang manu-mano:

   I-click ang "I-deploy", nakita namin na ang aming application ay lumitaw sa seksyon ng Mga Application:

   Gamit ang Tomcat GUI maaari nating ihinto ito, i-restart ito, itakda ang haba ng session at tanggalin ito. Kapag nagde-deploy, tinukoy namin ang konteksto /demo, na nangangahulugan na ang aming aplikasyon ay dapat ma-access sa pamamagitan ng link na http://localhost:8080/demo . Suriin, dapat gumana ang lahat.

2. Sa pamamagitan ng file system

   Upang mag-deploy ng application sa ganitong paraan, kailangan mong buksan ang direktoryo kung saan naka-unzip ang Tomcat at pumunta sa mga webapp. Narito ang mga utility application na pamilyar sa amin:

   Ang kailangan lang nating gawin ay ilipat ang ating servlet.war dito.

   Naghintay kami ng ilang segundo, nakita namin na lumitaw ang isang bagong folder ng servlet, na nangangahulugan na ang aming aplikasyon ay na-deploy. Pumunta tayo sa pamilyar na interface ng Application Manager - http://localhost:8080/manager/ . Dito makikita natin na ang aming aplikasyon ay naka-deploy sa /servlet na konteksto:

   Kapag na-deploy sa ganitong paraan, awtomatikong itinatalaga ang konteksto sa pangalan ng naka-deploy na archive ng digmaan. Upang baguhin ang konteksto, maaari mong palitan ang pangalan ng bagong likhang folder gamit ang application, ngunit bago iyon kailangan mong tanggalin ang file: kung hindi, muling i-redeploy ng Tomcat ang application gamit ang pangalan ng archive.

   Tulad ng nakikita mo, ang pag-deploy ng mga application sa Tomcat ay mas madali kaysa sa tila. Ngunit ang iba pang mga pag-andar nito ay madaling gamitin. Suriin natin.

Paggamit ng HTTPS protocol sa halip na HTTP

Kung naaalala mo, tinalakay namin ang pagkakaiba sa pagitan ng HTTP at HTTPS sa isang hiwalay na artikulo . Ang HTTPS ay ang parehong protocol bilang HTTP, ngunit gumagamit ng pag-encrypt ng data na inilipat. Sa panig ng kliyente, ang pag-encrypt ay pinangangasiwaan ng browser, at dapat kaming magbigay ng pag-encrypt sa gilid ng server. Dahil ang mga kahilingan sa HTTP ay tinatanggap at niruruta ng Tomcat, magiging lohikal na italaga ang pag-encrypt dito. Upang gawin ito kailangan mo:

1. Bumuo ng isang self-sign na sertipiko;
2. Gumawa ng karagdagang mga setting ng server.

Sanayin natin ito.

Pagbuo ng isang sertipiko

Ang JDK ay may kasamang malaking bilang ng mga utility, anuman ang bersyon, isa sa mga ito ay keytool . Ito ay isang tool para sa pagbuo ng mga susi sa pag-encrypt at pagtatrabaho sa kanila. Upang gamitin ito, gamit ang command line, pumunta sa C:\Program Files\Java\jdk1.8.0_181\bin directory at patakbuhin ang command keytool -genkey -alias tomcat -keyalg RSA .

• keytool - ilunsad ang utility na may mga parameter;
• -genkey - ipahiwatig na gusto naming bumuo ng isang bagong key;
• -alias tomcat - lumikha ng isang key alias;
• -keyalg RSA - piliin ang RSA bilang key generation algorithm.

Pagkatapos isagawa ang utos, magsisimula ang utility ng isang dialogue sa amin: Ipasok ang kinakailangang impormasyon. Ngayon ay nakagawa na kami ng keystore sa aming home directory (para sa Windows ito ay C:\Users\{username}\.keystore) at isang tomcat key dito. Nakabuo kami ng isang simpleng sertipiko na tatanggapin ng karamihan sa mga browser. Ang sertipiko na ito ay hindi angkop para sa mga komersyal na aplikasyon: maaari lamang itong gamitin para sa mga layunin ng pagsubok. Sa production server, dapat kang gumamit ng certificate mula sa certificate authority (halimbawa, https://letsencrypt.org/ ).

Pagse-set up ng server

Ngayon na handa na ang sertipiko, kailangan mong ayusin ang mga setting ng server, katulad ng SSL connector. Ginagawa ito sa server.xml file, na matatagpuan sa apache-tomcat-9.0.30/conf/ . Nakahanap kami ng mga bloke tulad ng:

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

at sa tabi nila inilalagay namin ang aming pagsasaayos:

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

Itinalaga namin ang keystoreFile at keystorePass na mga parameter ng mga value na nauugnay sa amin, i-save at i-restart ang Tomcat gamit ang shutdown.bat at startup.bat na mga file. Ngayon handa na ang server na iproseso ang mga kahilingan sa https, kaunti lang sa binagong address - https://localhost:8443/demo/hello . Kapag nag-click ka sa link, makakakita ka ng babala tungkol sa pagiging kaduda-dudang sertipiko, na hindi nakakagulat. Tulad ng inilarawan nang mas maaga, upang makakuha ng isang normal na sertipiko kailangan mong gamitin ang mga serbisyo ng isa sa mga serbisyo ng sertipikasyon. Ngunit sa ngayon ay nakamit namin ang aming layunin: gumagana ang application gamit ang HTTPS protocol, at ito ang pangunahing bagay!

Dynamic na henerasyon ng mga HTML na pahina

Ngayon ipagpatuloy natin ang aming pagsusuri sa iba pang mga tampok ng mga lalagyan ng servlet - dynamic na henerasyon ng mga pahina ng HTML. Isipin ang isang perpektong mundo kung saan, sa halip na nakakainip na static na HTML code, maaari kang magsulat ng JAVA code gamit ang mga variable, loop, array at iba pang mga construct ng wika. Naisip mo ba? Ang mabuting balita ay mayroong katulad na bagay, ang masamang balita ay hindi ito ganap na umiiral. Kung hindi mo nahulaan, pinag-uusapan natin ang teknolohiya ng JSP (Java Server Pages). Sa madaling salita, ito ay isang teknolohiya na nagpapahintulot sa iyo na magpasok ng mga piraso ng JAVA code sa isang HTML na pahina. Totoo, kung gayon ang code na ito ay ginawang HTML pa rin bago ipadala sa kliyente, ngunit ito ay dynamic na mabubuo na isinasaalang-alang ang iba't ibang mga kadahilanan. Halimbawa, maaari kang gumamit ng mga conditional construction at maghatid ng iba't ibang content depende sa ilang kundisyon. Halimbawa ng pahina ng 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>

Maaari kang magbasa ng higit pa tungkol sa JSP dito . Sa totoo lang... hindi kami nandito para dito, kundi para sa mga servlet container! Ano ang kinalaman ng JSP dito? Ito ay simple: ang pagbabago ng JAVA code mula sa JSP sa HTML code ay isinasagawa ng servlet container. Kapag malapit nang ibalik ng isang servlet ang nilalaman ng JSP bilang tugon, mapapansin ng container at gagawin muna itong isang HTML page na nababasa ng browser bago ipadala ang nilalamang iyon sa kliyente. Ngayon maraming mga analogue ng teknolohiya ng JSP - Thymeleaf, FreeMarket, Mustache at iba pa. Lahat sila ay gumagana sa isang katulad na prinsipyo. Alin ang pipiliin para sa trabaho ay isang bagay ng panlasa. Nalalapat din ito sa pagpili ng lalagyan ng servlet. Sa mga halimbawang ginamit namin ang Tomcat, ang pinakakaraniwang lalagyan, ngunit ang ilang proyekto ay gumagamit ng iba. Ito ay nagkakahalaga ng maikling pamilyar sa iyong sarili sa mga pinakasikat at tingnan ang kanilang mga pagkakaiba mula sa Tomcat.

Mga alternatibo sa Tomcat

1. Ang GlassFish ay isang open source na lalagyan na sinusuportahan ng Oracle.

   Hindi tulad ng Tomcat, ito ay isang ganap na web server na, bilang karagdagan sa mga servlet, ay maaaring magpatakbo ng iba pang mga bahagi mula sa JavaEE framework. Kasabay nito, gumagamit ito ng mas maraming RAM. Mas nababaluktot kapag pinino-pino ang server, na ginagawang mas mahirap gamitin. Ito ay nagkakahalaga ng paggamit kapag bumubuo ng mga application gamit ang JavaEE framework.

2. WildFly - dating Jboss . Open source din. Binuo ng Red Hat. Ang pangalan ay binago upang maiwasan ang pagkalito sa isa pang produkto ng kumpanya - JBoss Enterprise Application Platform.

   Ang WildFly, tulad ng GlassFish, ay isang ganap na web server. Sa pamamagitan ng paraan, sa ilalim ng talukbong ng WildFly ay gumagamit ng Tomcat bilang isang lalagyan ng servlet. Hindi tulad ng GlassFish, ang WildFly ay mas magaan at mas madaling i-set up.

3. Ang Jetty - katulad ng mga nauna, ay open source. Binuo ng Eclipse.

   Tulad ng Tomcat, ito ay isang simpleng servlet container, na walang suporta para sa lahat ng mga bahagi ng JavaEE framework. Kasabay nito, ito ay mas magaan at maaaring patakbuhin sa isang mobile phone. Nagsisimula at huminto ito nang mabilis at mahusay na kaliskis. Hindi tulad ng Tomcat, mayroon itong mas maliit na komunidad at base ng kaalaman.

4. Ang WebLogic ay lisensyadong software na nangangailangan ng pagbili bago gamitin. Pagmamay-ari ng Oracle.

   Kung ikukumpara sa Tomcat, medyo mas malawak ang functionality nito. Maaaring gumana sa ftp protocol. Ngunit hindi ito masyadong nababaluktot kapag bumubuo at sumusubok ng mga application.

5. Ang WebSphere (WebSphere Application Server upang maging tumpak) ay isang bayad na software. Binuo ng IBM. Katulad ng WildFly at GlassFish, isa itong ganap na server ng application. Ngunit mayroon itong mas magiliw na interface ng pag-setup, kasama ang mataas na pagiging maaasahan sa pagpapatakbo.

   Ang downside ay gumagamit ito ng maraming mapagkukunan, tumatagal ng mahabang oras upang magsimula at huminto, na hindi masyadong maginhawa kapag bumubuo ng maliliit na proyekto.

Aling servlet container o application server ang pipiliin ay depende sa partikular na proyekto. May mga proyekto kung saan kahit na ang isang halatang tagalabas ay magagawang patunayan ang kanyang sarili sa pinakamataas na kalidad, ngunit sa una ay mas mahusay na lubusang maunawaan ang isang bagay. Marahil ang perpektong kandidato para sa isang ito ay Tomcat. Nagawa na namin ang mga unang hakbang sa pag-aaral nito, at pagkatapos ay nasa iyo na! Sa mga huling artikulo ng seryeng "Introduction to Enterprise Development", makikilala natin ang pattern ng MVC. Bahagi 7. Panimula sa MVC pattern (Model-View-Controller) Part 8. Pagsusulat ng maliit na application sa spring-boot