Bahagi 6. Mga lalagyan ng Servlet

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

Sa huling artikulo, nakilala namin ang mga servlet at natutunan namin kung paano gamitin ang mga ito upang lumikha ng mga web application. Dumating na ang oras upang tingnang mabuti ang isang mahalagang bahagi ng kasiyahang ito: mga servlet container.

Talaan ng mga Nilalaman:

Ano ang isang lalagyan ng servlet?

Ito ay isang programa na tumatakbo sa isang 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 maglalagay kami ng mga servlet dito. Ang daloy ng trabaho ay simple: kapag na-access ng kliyente ang server, pinoproseso ng container ang kahilingan nito, tinutukoy kung aling servlet ang dapat magproseso nito, at pagkatapos ay ipapasa ang kahilingan. Bahagi 6. Mga lalagyan ng Servlet - 2

Paano ginagamit ang mga lalagyan ng servlet?

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

Ito ay dynamic na bumubuo ng mga HTML na pahina mula sa mga JSP file.
Ito ay nag-e-encrypt/nagde-decrypt ng mga HTTPS na mensahe.
Nagbibigay ito ng restricted access para sa servlet administration.

Sa pangkalahatan, maganda ang lahat ng ito. Ngayon kailangan lang nating malaman kung paano isasagawa ang lahat. Well, para matutunan kung paano gumamit ng isang bagay, sumisid lang at subukang gamitin ito :) Kaya, magsasanay tayo ngayon! Ang pinakasikat na lalagyan ng servlet ay Apache Tomcat . Ito ay open source at maaaring magamit nang libre. I-download ang Tomcat para sa iyong operating system dito at tutuklasin namin ang pagtatrabaho sa mga container na "nasa aksyon".

Pag-install at pagsisimula ng Tomcat

Upang i-install ang Tomcat, i-unzip lang ang na-download na archive sa nais na direktoryo.
Pakitandaan na ang Tomcat ay nangangailangan ng Java version 8 o mas mataas para magsimula at tumakbo. I-verify na ang JAVA_HOME environment variable ay tumutukoy sa kasalukuyang bersyon ng JDK.
Susunod, kailangan mong i-configure ang access ng user sa Tomcat . Ginagawa ito sa tomcat-users.xml file, na matatagpuan sa conf folder.

Mayroong apat na preset na tungkulin sa Tomcat:
- manager-gui — Pag-access sa graphical na interface at pahina ng katayuan
- manager-script — Access sa text interface at page ng status
- manager-jmx — Access sa JMX at sa pahina ng katayuan
- manager-status — I-access lamang sa pahina ng katayuan
Sa loob ng tag na <tomcat-users>, tahasan naming tinukoy ang mga tungkuling ito at itinalaga 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!
Sa folder ng bin, patakbuhin ang startup.bat file (startup.sh sa Linux).
Pagkatapos ng ilang segundo, buksan ang link na http://localhost:8080/ sa iyong browser. Makakakita ka ng isang graphical na dashboard:

Kung makakita ka ng menu na tulad nito, tumatakbo ang Tomcat.
Kung hindi ito tumatakbo, manu-manong suriin ang mga variable ng kapaligiran ng JAVA_HOME at CATALINA_HOME:
- JAVA_HOME — Dapat itong sumangguni sa kasalukuyang bersyon ng Java 8+.
- CATALINA_BASE — Dapat itong sumangguni sa Tomcat o wala (hindi ito dapat sumangguni sa isa pang bersyon ng Tomcat).

Pag-deploy ng application sa Tomcat

Nagawa naming ilunsad ang Tomcat, kaya oras na para mag-deploy ng ilang 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 mag-deploy, kailangan naming i-package ang aming mga servlet sa isang WAR file. Karaniwang ginagamit ang Maven para gawin ito, ngunit para makalikha ng WAR file kailangan mo ng web.xml file na may pagmamapa para sa lahat ng servlet. Ginamit namin ang bagong @WebServlet annotation para isulat ang mga servlet, kaya wala kaming web.xml file. Sa kabutihang palad, magagawa ng IDEA ang maruming gawain para sa amin, na binabalot ang aming proyekto sa isang WAR file. Upang gawin ito, buksan ang istraktura ng proyekto (Ctrl+Shift+Alt+S) -> Mga Artifact -> Piliin ang nais na WAR file -> Piliin ang checkbox sa tabi ng "Isama sa pagbuo ng proyekto" -> I-click ang "OK". Bahagi 6. Mga lalagyan ng Servlet - 4

Buuin natin ang proyekto gamit ang kumbinasyon ng Ctrl+F9 key. Ngayon ang aming WAR file ay nasa target na direktoryo Bahagi 6. Mga lalagyan ng Servlet - 5

Ang file ay maaaring palitan ng pangalan sa isang bagay na mas simple, hal servlet.war, at ilipat sa isang mas maginhawang lugar, hal C:\\my\\.ilalagay natin sa lalagyan . Mayroong dalawang paraan upang gawin ito.

Gamit ang graphical na interface

Upang gawin ito, sundan ang link na ito: http://localhost:8080/manager/html . Dapat humingi ng username at password ang Tomcat.

Kung sumunod ka sa akin hanggang sa puntong ito, ang username ay "user", at ang password ay "password" .

Pagkatapos ng matagumpay na pag-sign in, makikita mo ang Tomcat Web Application Manager. Ang seksyong "Applications" ay naglalaman na ng 5 application — ito ay mga Tomcat utilities, na ginagawang mas madaling gamitin ang Tomcat. Maaari silang tanggalin sa hinaharap.

Nasa ibaba ang seksyong "I-deploy." Dito maaari mong piliin ang WAR archive na i-deploy. Ipasok natin ang landas at konteksto nang manu-mano:

I-click ang "Deploy" at nakita namin na ang aming application ay lumitaw sa seksyong "Applications":
Gamit ang graphical interface ng Tomcat, maaari naming ihinto, i-restart, at tanggalin ang isang session, pati na rin itakda ang haba ng session. Kapag nagde-deploy, tinukoy namin ang konteksto ng /demo, na nangangahulugan na ang aming application ay na-access gamit ang http://localhost:8080/demo . Suriin ito. Lahat ay dapat gumana.
Sa pamamagitan ng file system

Upang i-deploy ang application sa ganitong paraan, kailangan mong buksan ang direktoryo kung saan na-unzip ang Tomcat. Pagkatapos ay pumunta sa folder na "webapps". Dito makikita mo ang mga utility na naranasan na namin:

Ang kailangan lang ay ilipat namin ang aming servlet.war file dito.

Naghintay kami ng ilang segundo at pagkatapos ay makita na may lumitaw na bagong "servlet" na folder. Nangangahulugan ito na ang aming aplikasyon ay na-deploy. Pumunta sa interface ng Application Manager sa 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 batay sa pangalan ng naka-deploy na WAR file. Upang baguhin ang konteksto, maaari mong palitan ang pangalan ng bagong likhang folder na naglalaman ng application, ngunit bago gawin iyon kailangan mong alisin ang WAR file. Kung hindi, muling ipapatupad ng Tomcat ang application na may 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 sa halip na HTTP

Kung naaalala mo, tiningnan namin ang pagkakaiba sa pagitan ng HTTP at HTTPS sa isang hiwalay na artikulo . Ang HTTPS ay kapareho ng protocol ng HTTP, ngunit ini-encrypt nito ang data na ipinapadala. Sa panig ng kliyente, ang browser ay may pananagutan para sa pag-encrypt, ngunit dapat naming ibigay ang pag-encrypt sa gilid ng server. Dahil ang Tomcat ay tumatanggap at nagruta ng mga kahilingan sa HTTP, makatuwirang italaga ang pag-encrypt dito. Upang gawin ito, dapat nating:

Bumuo ng isang self-sign na sertipiko
Gumawa ng karagdagang mga setting ng server

Magsanay tayo sa paggawa nito.

Pagbuo ng isang sertipiko

Anuman ang bersyon, ang JDK ay may kasamang malaking bilang ng mga kagamitan. Isa sa mga ito ay keytool . Ito ay isang tool para sa pagbuo at pagtatrabaho sa mga encryption key. Upang magamit ito, sa 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 — Ang pangalan ng utility na pinapatakbo namin na may mga opsyon sa command line
-genkey — Ipahiwatig na gusto naming bumuo ng bagong key
-alias tomcat — Lumikha ng key alias
-keyalg RSA — Piliin ang RSA bilang key generation algorithm

Pagkatapos isagawa ang utos, magsisimula ang utility ng isang dialogue sa amin: Bahagi 6. Mga lalagyan ng Servlet - 11

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 irereklamo ng karamihan sa mga browser. Ang nasabing sertipiko ay hindi angkop para sa mga komersyal na aplikasyon: maaari lamang itong gamitin para sa mga layunin ng pagsubok. Sa isang production server, kailangan mong gumamit ng certificate mula sa isang certification authority (halimbawa, https://letsencrypt.org/ ).

Pag-configure ng server

Ngayon na handa na ang sertipiko, kailangan nating ayusin ang mga setting ng server, ibig sabihin, ang SSL connector. Ginagawa ito sa server.xml file, na matatagpuan sa apache-tomcat-9.0.30/conf/ . Sa loob nito, nakakahanap kami ng mga bloke tulad nito:

<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 inilagay namin ang aming configuration sa tabi nila:

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

Nagtatalaga kami ng mga pinakabagong value sa keystoreFile at keystorePass na mga parameter, i-save ang file, at pagkatapos ay i-restart ang Tomcat gamit ang shutdown.bat at startup.bat na mga file. Ngayon ay handa na ang server na iproseso ang mga kahilingan sa HTTPS. Medyo nagbago lang ang address: https://localhost:8443/demo/hello . Kapag nag-click ka sa link makakatanggap ka ng babala tungkol sa pagiging mapagkakatiwalaan ng sertipiko, na hindi nakakagulat. Tulad ng sinabi namin nang mas maaga, kailangan mong gamitin ang mga serbisyo ng isa sa mga awtoridad sa sertipikasyon upang makakuha ng isang normal na sertipiko. Ngunit sa ngayon, nakamit namin ang aming layunin: tumatakbo ang application gamit ang HTTPS protocol, at mahalaga iyon!

Dynamic na pagbuo ng mga pahina ng HTML

Ngayon ay ipagpapatuloy namin ang aming pangkalahatang-ideya ng mga servlet container sa pamamagitan ng pagsasaalang-alang sa isa pang tampok: dynamic na henerasyon ng mga HTML na pahina. 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 ito? Ang mabuting balita ay mayroong isang katulad na bagay. Ang masamang balita ay hindi nito ganap na nakakamit ang pantasyang ito. Kung hindi mo nahulaan, pinag-uusapan natin ang tungkol sa JavaServer Pages (JSP). Sa madaling salita, ito ay teknolohiya na hinahayaan kang magpasok ng mga piraso ng Java code sa isang HTML na pahina. Totoo, ang Java code na ito ay kino-convert pa rin sa HTML bago ito ipadala sa kliyente, ngunit ang HTML na iyon ay dynamic na bubuo, na isinasaalang-alang ang iba't ibang mga kadahilanan. Halimbawa, maaari kang gumamit ng mga conditional statement at magbalik ng iba't ibang nilalaman 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 pagtatapos ng araw, ang artikulong ito ay hindi tungkol sa JSP — narito kami para pag-usapan ang tungkol sa mga servlet container! Kaya bakit namin binanggit ang JSP? Ito ay simple: isang servlet container ang nagko-convert ng Java code mula sa JSP patungo sa HTML. Kapag ang isang servlet ay magbabalik ng JSP na nilalaman bilang isang tugon, ang lalagyan ay mapapansin at unang iko-convert ito sa isang browser-friendly na HTML na pahina bago ipadala ang naturang nilalaman sa kliyente. Ngayon, maraming mga analogue sa teknolohiya ng JSP — Thymeleaf, FreeMarket, Mustache, at iba pa. Lahat sila ay gumagana sa isang katulad na paraan. Alin sa kanila ang pipiliin para sa iyong trabaho ay isang bagay ng panlasa. Nalalapat din ito sa pagpili ng lalagyan ng servlet. Sa mga halimbawang ito, ginamit namin ang Tomcat, ang pinakakaraniwang lalagyan, ngunit ang ilang proyekto ay gumagamit ng iba pang lalagyan. Kapaki-pakinabang na maikling suriin ang mga pinakasikat at isaalang-alang kung paano sila naiiba sa Tomcat.

Mga alternatibo sa Tomcat

Ang GlassFish ay isang open source na lalagyan na ang pag-unlad ay sinusuportahan ng Oracle.

Hindi tulad ng Tomcat, ito ay isang ganap na web server, na, bilang karagdagan sa mga servlet, ay maaaring gumana sa iba pang mga bahagi mula sa JavaEE framework. Iyon ay sinabi, gumagamit ito ng mas maraming RAM. Mayroong higit na kakayahang umangkop kapag pinino-pino ang server, na nagpapalubha sa paggamit nito. Dapat itong gamitin kapag bumubuo ng mga application sa JavaEE framework.
Ang WildFly ay dating kilala bilang JBoss . Open source din ito. Ito ay binuo ng Red Hat. Ang pangalan ay binago upang maiwasan ang pagkalito sa isa pa sa mga produkto ng kumpanya — JBoss Enterprise Application Platform.

Tulad ng GlassFish, ang WildFly ay isang ganap na web server. Nagkataon, sa ilalim ng hood, ginagamit ng WildFly ang Tomcat bilang isang servlet container. Hindi tulad ng GlassFish, ang WildFly ay mas magaan at madaling i-configure.
Ang Jetty , tulad ng mga nauna, ay open source. Ito ay 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.
Ang WebLogic ay lisensyadong software na dapat bilhin bago gamitin. Ito ay pag-aari ng Oracle.

Mayroon itong bahagyang mas malawak na pag-andar kaysa sa Tomcat. Maaari itong gumana sa FTP protocol. Ngunit hindi ito masyadong nababaluktot kapag bumubuo at sumusubok ng mga application.
Ang WebSphere (WebSphere Application Server, upang maging tumpak) ay bayad na software. Ito ay binuo ng IBM. Katulad ng WildFly at GlassFish, ito ay isang kumpletong server ng application. Ngunit mayroon itong mas magiliw na interface ng pagsasaayos, kasama ang mataas na pagiging maaasahan sa pagpapatakbo.

Kasama sa mga pagkukulang nito ang katotohanan na gumagamit ito ng maraming mapagkukunan at tumatagal ng mahabang panahon upang magsimula at huminto, na hindi masyadong maginhawa kapag bumubuo ng maliliit na proyekto.

Ang pagpili ng tamang servlet container o application server ay depende sa partikular na proyekto. May mga proyekto kung saan kahit na ang isang malinaw na underdog ay maaaring mapatunayang isang mahusay na pagpipilian, ngunit sa una ay pinakamahusay na gumawa ng isang malalim na pag-aaral ng isang servlet container. Tomcat ay marahil ang perpektong kandidato para sa pag-aaral na ito. At nagawa na namin ang mga unang hakbang sa pag-aaral nito, ngunit mula rito ay nasa iyo na! Sa mga huling artikulo ng seryeng "Introduction to Enterprise Development," malalaman natin ang pattern ng MVC. Bahagi 7. Ipinapakilala ang pattern ng MVC (Model-View-Controller).