JavaRush /בלוג Java /Random-HE /יישום אינטרנט ב-Java

רָמָה

28 February 2021
38 views
0 comments

יישום אינטרנט ב-Java

מבוא

פעם, ג'אווה חיזקה את מעמדה בשל העובדה שבחרה ביישומי אינטרנט בראש סדר העדיפויות. מאז ימיה הראשונים, ג'אווה נאבקה למצוא את דרכה. ראשית, הצעתי יישומונים. זה סיפק הזדמנויות רבות למפתחים ליצור תוכן דינמי בדפי HTML סטטיים. עם זאת, יישומונים לא עמדו בציפיות מסיבות רבות: אבטחה, תקורה ואחרות. ואז המפתחים של שפת Java הציעו חלופה - Servlet API . והתברר שזו הייתה החלטה נכונה. ה-API של Servlet הוא המפרט שעליו בנויה כל אפליקציית אינטרנט של Java, בין אם זו אפליקציה מבוססת אינטרנט או שירות אינטרנט שמחזיר מידע כמתבקש. לכן, הדרך להבנת אופן פעולת יישומי האינטרנט של Java מתחילה בהבנת ה-API של Servlet.

Servlet API

אז, ה-API של Servlet הוא מה שמפתחי השפה הציעו למפתחי Java. ה-API של Servlet הוא מפרט שאמור לענות על השאלות העיקריות שלנו. אתה יכול למצוא אותו כאן: " JSR-000340 JavaTM Servlet 3.1 Final Release for Evaluation ". הפרק " 1.1 מה זה Servlet? " אומר ש- servlet הוא רכיב אינטרנט המבוסס על טכנולוגיית Java שיוצר תוכן דינמי (כלומר, תוכן). "מבוסס ג'אווה" פירושו ש- servlet הוא מחלקת ג'אווה הקומפילה לתוך bytecode . Servlets מנוהלים על ידי מיכל servlet, הנקרא לפעמים Servlet Engine. מיכל servlet הוא הרחבה של שרת אינטרנט המספקת פונקציונליות של servlet. בתורם, servlets מספקים אינטראקציה עם הלקוח בפרדיגמת הבקשה/תגובה, אשר מיושמת על ידי מיכל ה-servlet. בפרק " 1.2 מה זה servlet Container? " נאמר שמיכל servlet הוא חלק משרת אינטרנט או שרת יישומים המספק שירותי רשת דרכם נשלחות בקשות ותגובות, בקשות ותגובות מבוססות MIME נוצרות ומעובדות . בנוסף, מיכלי servlet מנהלים את מחזור החיים של servlets (כלומר להחליט מתי ליצור אותם, למחוק אותם וכו'). כל מיכלי ה-servlet חייבים לתמוך בפרוטוקול HTTP כדי לקבל בקשות ולשלוח תגובות. כאן אני רוצה להוסיף ש-MIME הוא תקן, מפרט שמספר כיצד יש לקודד מידע ולעצב הודעות כך שניתן יהיה לשלוח אותן דרך האינטרנט.

שרת אינטרנט

שרת אינטרנט הוא שרת שמקבל בקשות HTTP מלקוחות ומספק להם תגובות HTTP (בדרך כלל יחד עם דף HTML, תמונה, קובץ או נתונים אחרים). המשאבים המבוקשים מזוהים על ידי כתובות אתרים. אחד משרתי האינטרנט הפופולריים ביותר עם תמיכת Servlet API הוא Apache Tomcat . רוב שרתי האינטרנט הם מכונות מורכבות המורכבות ממרכיבים שונים, שכל אחד מהם מבצע פונקציות ספציפיות. לדוגמה:

מחברים

- בכניסה יש לנו מחברים (כלומר מחברים) שמקבלים בקשות נכנסות מלקוחות. מחבר ה-HTTP ב-Tomcat מיושם באמצעות רכיב "Coyote". מחברים מקבלים נתונים מהלקוח ומעבירים אותם ל- Tomcat Engine. Servlet Container - Tomcat Engine, בתורו, מעבד את הבקשה המתקבלת מהלקוח באמצעות רכיב "Catalina", שהוא מיכל servlet. עיין בתיעוד של Tomcat: " סקירת אדריכלות " לפרטים נוספים. ישנם שרתי אינטרנט אחרים התומכים במפרט ה-API של Servlet. לדוגמה, " Jetty " או " Undertow ". הארכיטקטורה שלהם דומה, כך שהבנת העיקרון של עבודה עם מיכל servlet אחד, אתה יכול לעבור לעבוד עם אחר.

אפליקציית רשת

לכן, על מנת שנוכל להריץ אפליקציית אינטרנט, אנו זקוקים לשרת אינטרנט התומך ב-Servlet API (כלומר, כזה שיש לו רכיב הרחבה שמיישם תמיכת Servlet API עבור שרת האינטרנט). בסדר גמור. מה זה בכלל אפליקציית אינטרנט? לפי פרק " 10 יישומי אינטרנט " במפרט Servlet API, יישום אינטרנט הוא אוסף של servlets, דפי HTML, מחלקות ומשאבים אחרים המרכיבים יישום סופי בשרת אינטרנט. על פי הפרק " 10.6 Web Application Archive File ", ניתן לארוז יישום אינטרנט בארכיון Web ARchive (ארכיון עם סיומת WAR). כפי שצוין בדף " מילון מונחים-219 ":

כלומר, WAR נוצר במקום JAR כדי להראות שמדובר באפליקציית אינטרנט. העובדה החשובה הבאה: חייב להיות לנו מבנה ספריות מסוים בארכיון ה-WAR שלנו. במפרט Servlet API בפרק " 10.5 מבנה ספריות ". פרק זה אומר שיש ספרייה מיוחדת בשם "WEB-INF". ספרייה זו מיוחדת בכך שהיא אינה גלויה ללקוח ואינה מוצגת לה ישירות, אך היא נגישה לקוד servlet. זה גם אומר מה ספריית WEB-INF יכולה להכיל:

מכל הרשימה הזו, כעת איננו יודעים ואינם מבינים את הפריט על קובץ web.xml כלשהו שנקרא deployment descriptor . מה זה? הפרק " 14. מתאר פריסה " מוקדש לתיאור הפריסה. בקיצור, מתאר פריסה הוא קובץ xml שמתאר כיצד לפרוס (כלומר, להפעיל) את יישום האינטרנט שלנו בשרת אינטרנט. לדוגמה, מתאר הפריסה מציין באילו כתובות URL יש להשתמש כדי לגשת לאפליקציה שלנו, מצוינות הגדרות אבטחה הקשורות לאפליקציה שלנו וכו'. הפרק " 14.2 כללים לעיבוד הפריסה " אומר שהסכימה של web.xml תאושר לפני הגדרת התצורה וההפעלה של היישום שלנו (כלומר, תיעשה בדיקה שהתוכן של web.xml כתוב כהלכה בהתאם לסכימה) . ובפרק " 14.3 מתאר פריסה " מצוין שהתרשים נמצא כאן: http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd אם נסתכל על תוכן הקובץ, נוכל לראות:

באיזו סכימה משתמשים בקבצי XML? הסכמות מציינות כיצד למלא נכון מסמך XML: באילו אלמנטים ניתן להשתמש, איזה סוג נתונים ניתן לציין באלמנטים, באיזה סדר האלמנטים צריכים ללכת, אילו אלמנטים נדרשים וכו'. ניתן להשוות את הסכימה של מסמך XML עם ממשק ב-Java, מכיוון שהסכימה ב-Java מציינת גם כיצד יש לכתוב מחלקות העונות על ממשק נתון (כלומר, שמיישמות ממשק נתון). אז, אנחנו חמושים בידע סודי ומוכנים ליצור את יישום האינטרנט הראשון שלנו!

יצירת יישום אינטרנט

קשה לדמיין עבודה עם יישום Java מודרני מבלי להשתמש במערכות בניית פרויקטים אוטומטיות. כמה מהמערכות הפופולריות ביותר הן Maven ו- Gradle . אנו נשתמש ב- Gradle עבור סקירה זו. ההתקנה של Gradle מתוארת באתר הרשמי . כדי ליצור אפליקציה חדשה, אנחנו צריכים תוסף מובנה ב- Gradle: " Build Init Plugin ". כדי ליצור יישום Java עליך להפעיל את הפקודה הבאה: gradle init --type java-application

לאחר יצירת הפרויקט, נצטרך לערוך את הקובץ build.gradle . זהו מה שנקרא Build Script (לפרטים נוספים, ראה תיעוד Gradle: " כתיבת Build Scripts "). קובץ זה מתאר כיצד להרכיב את הפרויקט והיבטים אחרים של עבודה עם פרויקט Java. בלוק התוספים מתאר באילו " תוספי Gradle " יש להשתמש עבור פרויקט Gradle הנוכחי. תוספים מרחיבים את היכולות של הפרויקט שלנו. לדוגמה, הפלאגין המוגדר כברירת מחדל הוא " java ". תוסף זה משמש תמיד אם אנו זקוקים לתמיכה ב-Java. אבל אנחנו לא צריכים את התוסף " יישום ", כי... התיאור שלו מציין שהוא משמש ליצירת "יישום JVM בר הפעלה", כלומר. הפעלת יישומי JVM. אנחנו צריכים ליצור יישום אינטרנט בצורה של ארכיון WAR. ואם נחפש את המילה WAR בתיעוד של Gradle, נמצא את " תוסף מלחמה ". לכן, נציין את התוספים הבאים:

plugins {
    id 'java'
    id 'war'
}

גם ב- " War Plugin Default Settings " נאמר שהספרייה עם כל התוכן של אפליקציית האינטרנט צריכה להיות "src/main/webapp", צריכה להיות אותה ספריית WEB-INF שבה צריך להיות ה-web.xml ממוקם. בואו ניצור קובץ כזה. נמלא אותו קצת מאוחר יותר, כי... עדיין אין לנו מספיק מידע בשביל זה. בבלוק "תלות" אנו מציינים את התלות של הפרויקט שלנו, כלומר את אותן ספריות/מסגרות שבלעדיהם האפליקציה שלנו לא יכולה לעבוד. במקרה זה, אנו כותבים יישום אינטרנט, מה שאומר שאיננו יכולים לעבוד ללא ה-API של Servlet:

dependencies {
    providedCompile 'javax.servlet:javax.servlet-api:3.1.0'
    testCompile 'junit:junit:4.12'
}

providedCompile פירושו שאין צורך לכלול את התלות בארכיון ה-WAR שלנו של יישום האינטרנט: היא נחוצה רק לצורך הידור. וכאשר היא מבוצעת, התלות הזו תסופק על ידי מישהו אחר (כלומר, שרת האינטרנט). ובכן, אנו משאירים בסקריפט ה-build מידע על איזה מאגר תלות אנו רוצים להשתמש - כל התלות שצוינו יורדו ממנו:

repositories {
    jcenter()
}

אנחנו מסירים את כל השאר מקובץ הסקריפט של ה-build. כעת נערוך את המחלקה src\main\java\App.java. בואו נעשה מזה סרבלט. מפרט ה-API של Servlet בפרק " פרק 2. ממשק Servlet " קובע שלממשק Servlet יש יישום בסיס של HttpServlet , שאמור להספיק ברוב המקרים והמפתחים רק צריכים לרשת ממנו. ובפרק " 2.1.1 HTTP Specific Request Handling Methods " מצוינות השיטות העיקריות לעיבוד בקשות נכנסות. לפיכך, הבה נשכתב את המחלקה App.java:

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.PrintWriter;
import java.io.IOException;

public class App extends HttpServlet {
    public String getGreeting() {
        return "Hello world.";
    }

    public void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
 		// https://www.oracle.com/technetwork/java/servlet-142430.html
 		PrintWriter out = resp.getWriter();
 		out.println(this.getGreeting());
 		out.close();
 	}
}

אז נראה שהכל מוכן. כל מה שנותר הוא לכתוב את מתאר הפריסה בצורה נכונה. מהתרשים, העתק את הטקסט הבא אל web.xml:

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="..."
      version="3.1">
      ...
</web-app>

וגם את הנתיב לסכמה שמצוין בה: http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd עכשיו בואו נסתכל על דוגמה של איך web.xml צריך להיראות במפרט Servlet API. דוגמה זו ניתנת בפרק " 14.5.1 דוגמה בסיסית ". בואו נשלב את המצוין בתרשים עם הדוגמה המצוינת במפרט. אנחנו מקבלים את הדברים הבאים:

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
      http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
      version="3.1">
      <display-name>A Simple Web Application</display-name>
      <servlet>
		<servlet-name>app</servlet-name>
		<servlet-class>App</servlet-class>
	  </servlet>
	  <servlet-mapping>
		<servlet-name>app</servlet-name>
		<url-pattern>/app</url-pattern>
	  </servlet-mapping>
</web-app>

כפי שאתה יכול לראות, השתמשנו בסכימה וב-schemaLocation שצוינו קודם לכן. ותיאור היסודות עצמם נלקח מהדוגמה מפרק 14.5.1. אם עשינו הכל נכון, נבצע את משימת המלחמה הדרגה ללא שגיאות:

הפעלת אפליקציית אינטרנט

כיצד מופעלת אפליקציית אינטרנט? בואו נתמודד תחילה עם האפשרות המורכבת יותר. אמרנו בעבר שיש שרת אינטרנט Apache Tomcat שתומך ב- Servlet API. זה אומר שאנחנו יכולים לפרוס את ארכיון המלחמה שנאסף שלנו (הם אומרים גם "פרוס") בשרת הזה. בדף " הורד את Tomcat ", הורד את סוג המשלוח "הליבה" בפורמט zip מהקטע "הפצות בינאריות". ולפרק את הארכיון שהורדתי לספרייה כלשהי, למשל ב-C:\apache-tomcat-9.0.14. לפני הפעלת השרת, בואו נפתח את הקובץ לעריכה conf\tomcat-users.xmlונוסיף לו את השורה הבאה: <user username="tomcat" password="tomcat" roles="tomcat,manager-gui,admin-gui"/> כעת, בשורת הפקודה, עבור אל ספריית bin והפעל את catalina.bat start. כברירת מחדל, מסוף השרת יהיה זמין ב- http://localhost:8080/manager. פרטי הכניסה והסיסמה הם אותם אלו שציינו ב-tomcat-users.xml. ל- Tomcat יש ספריית "webapps", המכילה יישומי אינטרנט. אם אנחנו רוצים לפרוס את ארכיון המלחמה שלנו לשם. כאשר הרצנו בעבר את פיקוד המלחמה Gradle, \build\libs\נוצר ארכיון מלחמה בספרייה. זה מה שאנחנו צריכים להעתיק. לאחר ההעתקה, רענן את הדף http://localhost:8080/managerוראה:

לאחר השלמת http://localhost:8080/javaweb/app, נפנה לסרבלט שלנו, כי בעבר "מיפינו" (כלומר מיפינו) את בקשת /app לשרת האפליקציה. יש דרך מהירה יותר לבדוק איך האפליקציה עובדת. ומערכת ההרכבה עוזרת לנו בזה שוב. בסקריפט הבנייה של פרויקט Gradle שלנו, אנחנו יכולים להוסיף תוסף חדש " Gretty " למקטע התוספים: id "org.gretty" version "2.3.1" ועכשיו אנחנו יכולים לבצע מטלת Gradle כדי להפעיל את האפליקציה שלנו:gradle appRun

ראה " הוסף את התוסף grety והפעל את האפליקציה " לפרטים.

API של Spring ו- Servlet

סרבלים הם הבסיס לכל דבר. ואפילו ה-Spring Framework הפופולרי כעת הוא לא יותר מאשר תוספת ל- Servlet API. מלכתחילה, מסגרת האביב היא תלות חדשה עבור הפרויקט שלנו. לכן, בואו נוסיף אותו לסקריפט ה-build בבלוק התלות: compile 'org.springframework:spring-webmvc:5.1.3.RELEASE' בתיעוד Spring Framework יש פרק " 1.1. DispatcherServlet ". זה אומר ש-Spring Framework בנויה על דפוס "הבקר הקדמי" - זה כאשר יש servlet מרכזי שנקרא " DispatcherServlet ". כל הבקשות מגיעות לסרבלט זה, והוא מאציל שיחות לרכיבים הדרושים. אתה מבין, אפילו כאן יש סרבלטים. עליך להוסיף מאזין לתיאור הפריסה:

<listener>
	&ltlistener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

זהו מאזין אירועים בהקשר של servlet. כלומר, כאשר ה-Servlet Context מתחיל, מתחיל גם ה-Spring context (WebApplicationContext). מהו הקשר Servlet? זה מתואר במפרט Servle API בפרק " פרק 4. Servlet Context ". הקשר של servlet הוא "תצוגה" של servlet של יישום האינטרנט שבתוכו פועלים ה-servlets. לכל יישום אינטרנט יש הקשר Servlet משלו. לאחר מכן, כדי להפעיל את Spring Framework, עליך לציין context-param - פרמטר האתחול עבור הקשר servlet.

<context-param>
	<param-name>contextConfigLocation</param-name>
	<param-value>/WEB-INF/app-context.xml</param-value>
</context-param>

וההגדרה של DispatcherServlet משלימה את התצורה :

<servlet>
	<servlet-name>app</servlet-name>
	<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
	<init-param>
		<param-name>contextConfigLocation</param-name>
 		<param-value></param-value>
	</init-param>
	<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
	<servlet-name>app</servlet-name>
	<url-pattern>/</url-pattern>
</servlet-mapping>

ועכשיו אנחנו רק צריכים למלא את הקובץ שצוין בהקשר ConfigLocation. כיצד לעשות זאת מתואר בתיעוד ה-Spring Framework בפרק "1.3.1. הצהרה":

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:p="http://www.springframework.org/schema/p"
    xmlns:mvc="http://www.springframework.org/schema/mvc"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="
        http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/context
        http://www.springframework.org/schema/context/spring-context.xsd
        http://www.springframework.org/schema/mvc
        http://www.springframework.org/schema/mvc/spring-mvc.xsd">

    <context:component-scan base-package="ru.javarush.javaweb"/>
    <mvc:annotation-driven/>
</beans>

חשוב כאן לא רק לציין איזו חבילה לסרוק, אלא גם שאנחנו רוצים מונעי הערות, כלומר לשלוט בהערות כיצד יפעל Spring. כל מה שנותר הוא ליצור את חבילת ru.javarush.javaweb ולמקם בה את מחלקת הבקר Spring:

package ru.javarush.javaweb;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.ResponseBody;

@Controller
public class SpringController {

    @GetMapping("/app")
    @ResponseBody
    public String getGreeting() {
        return "Hello world.";
    }
}

כעת מפעילים את gradle appRun ונעבור לכתובת, http://127.0.0.1:8080/javaweb/appנקבל את אותו Hello World. כפי שאתה יכול לראות, ה-Spring Framework שזורה באופן הדוק עם ה-API של Servlet ומשתמשת בו כדי לעבוד עליו.

הערות

כפי שראינו, הערות הן נוחות. ולא היינו היחידים שחשבו כך. לכן, במפרט Servlet API, החל מגרסה 3.0, הופיע הפרק " CHAPTER 8 Annotations and pluggability ", המציין שמיכלי servlet חייבים לתמוך ביכולת לציין את מה שצוין קודם לכן ב-Deployment Descriptor באמצעות הערות. כך, ניתן להסיר את web.xml לחלוטין מהפרויקט, ומעל למחלקת ה-servlet ניתן לציין את ההערה @WebServlet ולציין לאיזה נתיב למפות את ה-servlet. הכל נראה ברור כאן. אבל מה אם חיברנו את אביב לפרויקט, שדורש הגדרות מורכבות יותר? כאן הכל קצת יותר מסובך. ראשית, התיעוד של Spring אומר שכדי להגדיר את Spring ללא web.xml, עליך להשתמש במחלקה משלך שתטמיע את WebApplicationInitializer. לפרטים נוספים, עיין בפרק " 1.1. DispatcherServlet ". מסתבר שמדובר בשיעור אביב. כיצד אם כן משמש ה-API של Servlet כאן? למעשה, ה-ServletContainerInitializer נוסף ל-Servlet API 3.0 . באמצעות מנגנון מיוחד ב-Java (נקרא SPI ), Spring מציין את מאתחול מיכל ה-servlet שלו בשם SpringServletContainerInitializer. בתורו, הוא כבר מחפש יישומים של WebApplicationInitializer וקורא לשיטות הדרושות ומבצע את ההגדרות הדרושות. ראה " כיצד מיכל servlet מוצא יישומי WebApplicationInitializer " לפרטים נוספים. ניתן לבצע את ההגדרות לעיל כך:

package ru.javarush.javaweb.config;

import org.springframework.web.WebApplicationInitializer;
import org.springframework.web.context.ContextLoaderListener;
import org.springframework.web.context.support.AnnotationConfigWebApplicationContext;
import org.springframework.web.servlet.DispatcherServlet;

import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.ServletRegistration;

public class AppInitializer implements WebApplicationInitializer {
    @Override
    public void onStartup(ServletContext servletContext) throws ServletException {
        AnnotationConfigWebApplicationContext ctx = new AnnotationConfigWebApplicationContext();
        // регистрируем конфигурацию созданую высше
        ctx.register(AppConfig.class);
        // добавляем в контекст слушателя с нашей конфигурацией
        servletContext.addListener(new ContextLoaderListener(ctx));

        ctx.setServletContext(servletContext);

        // настраиваем маппинг Dispatcher Servlet-а
        ServletRegistration.Dynamic servlet =
                servletContext.addServlet("dispatcher", new DispatcherServlet(ctx));
        servlet.addMapping("/");
        servlet.setLoadOnStartup(1);
    }
}

כעת, באמצעות " תצורה מבוססת ג'אווה " נציין איזו חבילה לסרוק + הפעלת הערות:

package ru.javarush.javaweb.config;

import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.EnableWebMvc;

@Configuration
@EnableWebMvc
@ComponentScan(basePackages = "ru.javarush.javaweb.controllers")
public class AppConfig {
}

ו-SpringController עצמו הועבר ל- ru.javarush.javaweb.controllers, כך שבעת הסריקה, התצורה לא תמצא את עצמה, אלא רק תחפש בקרים.

תִמצוּת

אני מקווה שסקירה כללית זו שפכה מעט אור על איך יישומי אינטרנט עובדים ב-Java. זה רק קצה הקרחון, אבל בלי להבין את היסודות, קשה להבין איך עובדות טכנולוגיות המבוססות על הבסיס הזה. ה-API של Servlet הוא החלק המרכזי בכל יישום אינטרנט של Java, ובדקנו כיצד מסגרות אחרות משתלבות בו. כדי להמשיך, תוכל לצפות בחומרים הבאים:

#ויאצ'סלב

הערות

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