בלי פאתוס. בואו נדבר על Java EE, servlets והמכולות שלהם

בנושא זה, ברצוני לדבר בכנות על ההבנה שלי לגבי servlets, מה הם קונטיינרים של servlet, מה הם רוב, אם לא כולן, מסגרות חזית האינטרנט, וגם לגעת בנושא של האופן שבו קונטיינרים של servlet ושרתי יישומים קשורים אחד את השני, ומכולות servlet ושרת אינטרנט. לפני תחילת השיחה, אני רוצה לציין שאני באמת מצפה שיהיה דיון, כי... כאן אני לא רוצה לתת פיסת קוד אחת, אלא רק רוצה לגעת במהות, שתמיד אפשר לומר במילים. אנסה לשרטט את כל אותן נקודות שלא היו ברורות לי כשהתחלתי. כששאלתי שאלות בפורומים שונים בנושא של ההבדל בין מיכל הסרבלים של Tomcat מכל שרת יישומים, נגיד WebSphere או Geronimo, האנשים היחידים שהעזו לענות היו מטומטמים שלא יכלו לומר שום דבר מלבד "תסתכל בוויקיפדיה" או " קשה לומר, יישומי שרת - זו תשתית מורכבת ליישומים ארגוניים, ש..." בלה בלה בלה. אני לא סובל אנשים כאלה ואני מניח שגם רובכם לא. נתקן עוול היסטורי. ללכת…

סרבלים

לא משנה מה מישהו אומר, servlet הוא דף אינטרנט שנכתב ב-Java. יש שיגידו שאני טועה ושסרבלט הוא אפליקציית אינטרנט ושיש הבדל במושגים האלה, אבל זה לא כך. כעת אין הבדל, ואתרים שנכתבו ב-PHP יכולים להיקרא בבטחה גם יישומי אינטרנט. עכשיו זה טבעי לחלוטין, כי... php תומך באופן מלא ב- OOP, ומערכות CMS כגון Joomla משתמשות בזה באופן פעיל. מהו servlet ברמת הקוד? זוהי מחלקה שיש לה מספר שיטות שינה ורואות אם מישהו ניגש אליהן באמצעות בקשות GET או POST HTTP. הָהֵן. הקלדנו בקשת GET כלשהי בדפדפן, השיטה המתאימה של מחלקת ה-servlet מקבלת אותה ואז מייצרת לה תגובה בצורה של דף HTML. במובן הקלאסי של סרבלט, כפי שהוא נבנה על ידי Sun, דף זה נשלח ללקוח שורה אחר שורה, החל בשורה <!DOCTYPE htm>> וכלה בשורה </html>. אז ב-Java יש מחלקה בסיסית של servlet שנקראת Servlet. בנוסף, יש עוד המון מחלקות שיורשות ממחלקת הבסיס הזו ובכך מרחיבות את הפונקציונליות שלה. זה מה שזה סרבל - לא יותר מזה. זה רק אנלוגי ג'אווה של קוד PHP, שמבוצע גם בשרת, ורק התגובה לבקשת דפדפן האינטרנט בצורת דף אינטרנט נשלחת ללקוח. את כל.

מסגרות חזית אינטרנטיות

הכתובית מסובכת ובדרך כלל כותבים רק מסגרת חזיתית או אפילו web muzzle , אבל החלטתי להדגיש כאן שכשמדברים על מסגרת חזיתית, מדברים על GUI לעבודה עם ג'אווה דרך דפדפן אינטרנט. הָהֵן. כאן שוב אנחנו מדברים על אתרים בג'אווה, כלומר. לגבי סרבלטים. מה זה כמעט כל מסגרת חזיתית, למשל, Apache Struts. זה פשוט קבוצה של מחלקות שמרחיבות את מחלקת הבסיס Servlet. שום דבר יותר. הָהֵן. זו פשוט דרך אחרת ליצור את אותו סרבלט רגיל. רק שהמפתחים של המסגרת הזו (או במילים אחרות, מפתחי הטכנולוגיה הזו) חשבו שהתוספת שלהם של מחלקת הבסיס Servletעם שיטות מסוימות תהיה נוחה יותר למתכנת מאשר הפונקציונליות הדלה של ה-servlet הקלאסי של Sun/Oracle יש ל.

דפי JSP

כמעט מיד עלה רעיון נוסף בראשם של מפתחי קונספט ה-Java servlet. מכיוון שאנו כותבים servlet, שתפקידו לשלוח דף html ללקוח, אז אולי נכון יותר לכתוב מיד את דף ה-html הזה, ואם אתה צריך סוג של היגיון ב-Java, פשוט הכנס אותו ישירות לתוך ה-html. אם זה לא הופך ברור יותר, אז הביטוי עשוי לעזור: דף jsp הוא אנלוגי של דף php. קָשֶׁה? ואז אסביר שוב. מה אנחנו עושים כשכותבים דף ב-PHP? יש לנו html סטטי, וכשאנחנו צריכים להכניס כל היגיון ב-PHP כמו לולאות ותנאים, אנחנו מכניסים אותו לגוף התג <?php … ?>. עם jsp הכל אותו דבר, רק ההיגיון כתוב ב-Java טהור, שהקוד שלו מוכנס לגוף התג <% … %>. נחזור שוב למושג סרבל. במהותו, דף JSP הוא servlet, אך כתוב בצורה שונה במקצת. בסרבלט רגיל, אנו כותבים שיטה שמבצעת לוגיקה מסוימת ובהתבסס על התוצאות שלה, מייצרת דף HTML עבור הלקוח. רק שאחרי זמן מה, מפתחי ה-servlet התחילו לחשוב: מה אם אין כמעט היגיון בשיטה, ומתרחשת כמעט רק היווצרות של דף HTML, אז האם לא יהיה קל יותר לכתוב מיד דף HTML לתוך מה לעשות הוספת Java מינימלית? ובכן, דבר אחרון לגבי דפי jsp. בפעם הראשונה שניגשים לדף כזה, הוא נערך ל-servlet ואז מבוצע. בקשות עוקבות לדף jsp זה יהיו מהירות יותר מכיוון זה כבר יהיה קומפילד ורק יהיה צורך לבצע אותו.

מיכל סרבל

אז כתבנו מחלקת servlet או דף JSP. מה הלאה? איך לדחוף אותם לשרת אינטרנט, נגיד אפאצ'י, כדי שיוכל לשלוח אותם לדפדפן האינטרנט של המשתמש? שרת האינטרנט יכול לשלוח רק html, ואם לדף שלנו יש, נניח, קוד php, אז שרת האינטרנט מעביר את העמוד קודם כל דרך מתורגמן שמתרגם php ל-html, ורק אז התוצאה נשלחת ללקוח. בערך אותו דבר קורה עם servlets - לפני השליחה צריך להפעיל אותם על מנת שעמוד ה-HTML יווצר, והמיכל servlet הוא בדיוק הדבר שאחראי על ביצוע servlets וקוד עמוד jsp. הָהֵן. מיכל servlet עבור java הוא אנלוגי של מודול המתורגמן php בשרת אינטרנט. לפיכך, כאשר המשתמש מזין כתובת בדפדפן האינטרנט, הבקשה נשלחת לשרת האינטרנט, שרת האינטרנט מבין שמתבקש servlet ומעביר את הבקשה למיכל ה-servlet. לאחר מכן, מיכל ה-servlet מבצע את ה-servlet, שולח את דף ה-HTML המתקבל לשרת האינטרנט, אשר בתורו מחזיר אותו ללקוח. האם מיכל servlet יכול לפעול בכוחות עצמו, כלומר. בלי שרת אינטרנט? משהו כמו Tomcat בהחלט יכול. ואם אנחנו רוצים ליצור אתר שלא יהיו בו דפי HTML אחרים מלבד אלו המבוססים על servlets, אז מיכל servlet מספיק לנו. אבל אם אנחנו רוצים לשלב אתר מ-servlets, למשל, דפי PHP, אז נצטרך להתקין שרת אינטרנט. יתר על כן, לא בכל שרתי האינטרנט יש מיכל servlet כלול כברירת מחדל, אבל כמעט כולם מאפשרים לך להתקין אותו בתור תוסף. לכן, אם ברצוננו להשיק את האתר שלנו באירוח כלשהו באינטרנט, שבו ככל הנראה Apache פועל, אז נצטרך לשאול את הספק אם מיכל ה-servlet מחובר.

Java EE

יש את מה שנקרא JavaSE (Java Standard Edition). תפיסה זו כוללת את כל המחלקות java, שלשמן אנו רק צריכים לייבא אותן (לדוגמה, java.util.Date) או אפילו לא צריך לעשות זאת (לדוגמה, Stringמכיוון שהיא ממוקמת בחבילה java.lang). ויש את Java EE (Java Enterprise Edition). גם מחלקות אלו שייכות לסאן/אורקל, אך ההבדל היחיד הוא שקשה יותר להתחיל להשתמש בהן בפרויקט. קו פשוט import…לא יספיק, כי... הפרויקט לא יתבצע קומפילציה. על מנת לתקן את המצב, תצטרך למצוא את קובץ הספרייה javaee.jar ולכלול אותו בפרויקט. ניתן לעשות זאת באמצעות מאפייני הפרויקט בסביבת הפיתוח. לעתים קרובות אומרים שתהליך חיבור זה נקרא: רשום כינוי של jar בנתיב הבנייה או ה-classpath של הפרויקט.

שרת יישומים

כעת תארו לעצמכם שהרכבנו את פרויקט ה-servlet שלנו שמשתמש ב-Java EE. הכל נהדר, אבל עכשיו אנחנו צריכים למקם את המחלקות הקומפיליות שלנו במיכל servlet. נגיד שהם עשו את זה. האם האפליקציה שלנו תעבוד? התשובה היא לא. בעת גישה ל-servlet, ייזרקו חריגים המציינים שחלק מהשיעורים לא נמצאו. למה? כי "הטעינו" את המהדר בהחלקה javaee.jar в classpath, כלומר. המהדר ראה שהמחלקות מ-Java EE היו במקום ונרגע, אבל מיכל ה-servlet לא רואה את המחלקות האלה, אבל הוא רואה קישורים אליהם מה-servlet שלנו. האם מצב זה ניתן לפתרון בתוך מיכל servlet? כמובן שכן, אתה רק צריך להוסיף את קובץ הספרייה javaee.jar לתיקיה עם ה-servlet שלנו במיכל ה-servlet . עכשיו תארו לעצמכם שיהיו הרבה פרויקטים כאלה וכולם פועלים במיכל servlet אחד של Tomcat. זה אומר שתצטרך להעתיק את קובץ ה-jar לתיקיה של כל servlet. זה לא נוח ולא נכון. המצב נפתר על ידי הצגת הקונספט של שרת יישומים, שבו הקובץ הזה נמצא כבר זמן רב בעותק בודד, וכל הסרבלטים יכולים לגשת אליו, ואין להם עותק משלהם. לדעתי זה מאוד נוח והגיוני. מטבע הדברים, כל המהומה לא נובעת מקובץ jar אחד (נתתי אותו כדוגמה) - יש הרבה קבצים כאלה. אבל זה לא כל מה ששרתי יישומים נותנים לנו. שרתי יישומים עצמם יכולים לשמור על חיבורים למשאבים רבים, למשל, מסד נתונים. במקרה זה, ה-servlet שלנו עשוי שלא לפתוח חיבור כזה בעצמו, אלא פשוט לקחת אותו משרת היישומים. במיכל סרבל, זה בלתי אפשרי, כי... מיכל הוא, במידה מסוימת, שרת יישומים מפורק. במיכל, servlet חייב תמיד ליצור חיבורים למסד הנתונים עצמו. משהו כזה... ארכיון מלחמה מהו ארכיון מלחמה? WAR הוא ארכיון אינטרנט. למעשה, זה רק קובץ zip, כמו כל צנצנת. בעיקרון, זו רק דרך לדחוס את האתר שלנו, המורכב מדפי אינטרנט רבים, דפי jsp ומחלקות servlet, לקובץ zip אחד. web.xml web.xml הוא מה שנקרא מתאר הפריסה. זהו קובץ שמתאר בטיפשות איזו בקשת שורה של דפדפן אינטרנט לשלוח לאיזה מחלקה של servlet לעיבוד, כדי שה-servlet container לא יתבלבל, איזה servlet אחראי למה. באופן כללי, בג'אווה מאוד אופנתי לתאר הגדרות בכל מיני קבצי xml, אבל לאחרונה יש נטייה להתרחק מהמסורת הזו. איך, אתם שואלים? ובאמצעות הערות. מחלקות הערות עצמן לא עושות כלום; הן נוצרו רק כדי לתאר כל מיני הגדרות (מטא-נתונים) לא בקובץ xml נפרד, אלא ישירות בקוד. בנוחות רבה. עם זאת, כעת יש שלב ביניים מסוים, כאשר חלק מההגדרות מוגדרות על ידי הערות, וחלק על ידי xml, וזה יכול להיות מבלבל, כי אתה מסתכל על ה-xml ורואה הגדרה אחת, אבל לפי ההערות יש הגדרה אחרת. למי מהם יש את העדיפות הגבוהה ביותר? מי יודע…

סיכום

לאחר שכתבתי את זה, חשבתי שסקירה מהירה כזו לא תעזור לאף אחד, כי... לא מכיל שום פירוט וללא דוגמאות, אבל מצד שני, אל תמחק את מה שכתוב, אז שיהיה.