מבוא ל-Java EE

היום נדבר על מה זה - Java EE: ממה זה מורכב, מהן התכונות של הארכיטקטורה של יישומי Java EE, ונספק תיאורים של הטכנולוגיות השונות של פלטפורמה זו. הנושא עצמו נרחב, אך לא נעצור ביסודות. בסוף נערוך השוואה קטנה של Java EE עם Spring Framework ונענה על השאלה: "מה עדיף ללמוד" (ספוילר: כמובן שצריך ללמוד הכל =) ) נתחיל עם הבסיס.

Java EE - מה זה?

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

פיתוח Java EE

Java EE פותח באמצעות תהליך הקהילה של Java (JCP), שהוקם ב-1998. זה מאפשר למעוניינים להשתתף בעיצוב גרסאות עתידיות של מפרטי פלטפורמת השפות Java. הבסיס לתהליך זה הוא JSR (Java Specification Request), מסמכים פורמליים המתארים את המפרטים והטכנולוגיות המוצעים להתווסף לפלטפורמת Java. בקשות כאלה נעשות על ידי חברי הקהילה - מפתחים וחברות רגילות. האחרונים כוללים את Oracle, Red Hat, IBM, Apache ועוד רבים אחרים. הָהֵן. החבר'ה מציעים תכונות חדשות ודברים טובים שהם רוצים לכלול ב-Java. ואז הם עורכים הצבעה, שעל בסיסה מתקבלת החלטה מה לכלול בגרסה הבאה. היסטוריית הגרסאות של Java EE נראית כך:

• J2EE 1.2 (דצמבר 1999)
• J2EE 1.3 (ספטמבר 2001)
• J2EE 1.4 (נובמבר 2003)
• Java EE 5 (מאי 2006)
• Java EE 6 (דצמבר 2009)
• Java EE 7 (מאי)
• Java EE 8 (אוגוסט 2017)
• Jakarta EE 8 (ספטמבר 2019)

בשנת 2017 התרחשה אבן דרך חדשה בפיתוח הפלטפורמה: אורקל העבירה את השליטה בפיתוח Java EE לקרן Eclipse. ובאפריל 2018, השם של Java EE שונה ל-Jakarta EE, אשר תואם באופן מלא ל-Java EE 8.

ארכיטקטורת יישומים של Java EE

הקדמה קצרה. כדי להקל על ההבנה, בואו נדבר על המבנה של יישומי Java EE וכמה מהמונחים שבהם נשתמש בהמשך. ליישומי Java EE יש מבנה בעל שתי איכויות מפתח:

• ראשית, רב רמות. יישומי Java EE הם רב-שכבתיים, ואנו נדבר על כך ביתר פירוט;
• שנית, קינון. יש שרת Java EE (או שרת יישומים), עם מיכלי רכיבים שנמצאים בתוכו. מיכלים אלו מכילים רכיבים (בינגו!).

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

רמות יישום

יישומים מרובי שכבות הם יישומים המחולקים לפי עקרונות פונקציונליים למודולים מבודדים (רמות, שכבות). בדרך כלל (כולל בהקשר של פיתוח Java EE), יישומים ארגוניים מחולקים לשלוש רמות:

• לָקוּחַ;
• רמה ממוצעת;
• רמת גישה לנתונים.

1. שכבת הלקוח היא אפליקציה המבקשת נתונים משרת Java EE (השכבה האמצעית). השרת, בתורו, מעבד את בקשת הלקוח ומחזיר לה תגובה. אפליקציית הלקוח יכולה להיות דפדפן, אפליקציה עצמאית (נייד או שולחני), או יישומי שרת אחרים ללא ממשק גרפי.

2. רמת הביניים מחולקת, בתורה, לרמת האינטרנט ולרמת ההיגיון העסקי.

   1. שכבת האינטרנט מורכבת מכמה רכיבים המספקים אינטראקציה בין לקוחות לשכבת ההיגיון העסקי.

      נעשה שימוש בטכנולוגיות Java EE הבאות ברמת האינטרנט:

      • טכנולוגיית JavaServer Faces (JSF);
      • Java Server Pages (JSP);
      • שפת ביטוי (EL);
      • סרבלים;
      • הקשרים והזרקת תלות עבור Java EE (CDI).

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

      טכנולוגיות המעורבות ברמה זו:

      • Enterprise JavaBeans (EJB);
      • שירותי אינטרנט של JAX-RS RESTful;
      • ישויות Java Persistence API;
      • שירות הודעות Java.

3. רמת גישה לנתונים. רמה זו נקראת לעיתים רמת מערכות המידע הארגוניות (EIS). EIS מורכב משרתי מסדי נתונים שונים, ERP (Enterprise Resource Planning) מערכות תכנון משאבים ארגוניים ומקורות נתונים אחרים. שכבת הלוגיקה העסקית ניגשת לשכבה זו לצורך נתונים.

   ברמה זו ניתן למצוא טכנולוגיות כגון:

   • Java Database Connectivity API (JDBC);
   • Java Persistence API;
   • ארכיטקטורת מחברים של Java EE;
   • Java Transaction API (JTA).

שרתי יישומים, קונטיינרים, רכיבים

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

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

2. ה- Application Client Container (ACC) מכיל קבוצה של מחלקות Java, ספריות וקבצים אחרים הדרושים ליישום תכונות כגון הזרקה, ניהול אבטחה ושירותי שמות ביישומי Java SE.

3. קונטיינר האינטרנט מספק את שירותי הליבה לניהול וביצוע רכיבי אינטרנט (servlets, רכיבי EJB Lite, דפי JSP, מסננים, מאזינים, דפי JSF ושירותי אינטרנט). הוא אחראי על מופע, אתחול והפעלת servlets, ותמיכה בפרוטוקולי HTTP ו-HTTPS. מיכל זה משמש לשרת דפי אינטרנט לדפדפני לקוחות.

4. מיכל EJB (Enterprise Java Bean) אחראי על ניהול וביצוע רכיבי מודל ה-EJB המכילים את שכבת הלוגיקה העסקית של האפליקציה. היא יוצרת ישויות שעועית EJB חדשות, מנהלת את מחזור החיים שלהן, ומספקת שירותים כמו עסקאות, אבטחה, במקביל, הפצה, מתן שמות או יכולות הפעלה אסינכרונית.

כמו כן ב-Java EE ישנם ארבעה סוגים של רכיבים שיישום של מפרט Java EE חייב לתמוך בהם:

1. יישומונים הם יישומי ממשק משתמש גרפי (GUI) הפועלים בדפדפן. הם ממנפים את ה-API העשיר של Swing כדי לייצר ממשקי משתמש רבי עוצמה.

2. אפליקציות הן תוכנות הפועלות בצד הלקוח. בדרך כלל הם ממשק משתמש גרפי (GUI) ומשמשים לעיבוד אצווה.

3. יישומי אינטרנט (המורכבים משרתים ומסננים שלהם, מאזינים לאירועי אינטרנט, דפי JSP ו-JSF) - פועלים בקונטיינר אינטרנט ומגיבים לבקשות HTTP של לקוחות אינטרנט. Servlets תומכים גם בנקודות קצה של שירות אינטרנט של SOAP ו-RESTful.

4. יישומים ארגוניים (הבנויים עם Enterprise Java Beans, Java Message Service, Java Transaction API, שיחות א-סינכרוניות, שירותי זמן) פועלים במיכל EJB. EJBs המנוהלים במכולות מטפלים בלוגיקה עסקית עסקית. ניתן לגשת אליהם באופן מקומי או מרחוק באמצעות RMI (או HTTP עבור שירותי אינטרנט SOAP ו-RESTful).

התרשים שלהלן מציג ארכיטקטורת יישומי Java EE טיפוסית:

טכנולוגיות

אז, סידרנו את הארכיטקטורה. המבנה הכללי צריך להיות ברור. בתהליך תיאור הרכיבים הארכיטקטוניים נגענו בכמה טכנולוגיות Java EE כמו EJB, JSP וכו'. בואו נסתכל עליהם מקרוב. הטבלה שלהלן מציגה את הטכנולוגיות המשמשות בעיקר ברמת הלקוח: הטבלה שלהלן מציגה את הטכנולוגיות המשמשות ברמת ההיגיון העסקי: הטבלה שלהלן מציגה את הטכנולוגיות המשמשות בשכבת הגישה לנתונים:

Java EE נגד אביב

ה-Spring Framework נחשבת למתחרה ל-Java EE. אם מסתכלים על הפיתוח של שתי הפלטפורמות הללו, מצטיירת תמונה מעניינת. הגרסאות הראשונות של Java EE נוצרו בהשתתפות IBM. הם התגלו כמגניבים, אבל מגושמים, כבדים ולא נוחים לשימוש. מפתחים נאבקו בגלל הצורך לשמור על מספר רב של קבצי תצורה וסיבות אחרות שמקשות על הפיתוח. במקביל, אביב IoC נולד. זו הייתה ספרייה קטנה, יפה ונוחה לשימוש. הוא השתמש גם בקובץ תצורה, אבל בניגוד ל-Java EE, היה רק ​​אחד. הפשטות של אביב הובילה לכך שכמעט כולם החלו להשתמש במסגרת זו בפרויקטים שלהם. ואז Spring ו-Java EE התחילו את דרכם לאותו דבר, אבל ממטרות שונות. Pivotal Software, המפתחת של Spring, החלה לשחרר פרויקט אחר פרויקט כדי לכסות את כל הצרכים האפשריים והבלתי אפשריים של מפתחי Java. בהדרגה, מה שנקרא בעבר אביב הפך תחילה לאחד הפרויקטים, ולאחר מכן התמזג לחלוטין עם מספר פרויקטים אחרים ב-Spring Core. כל זה הוביל לסיבוך הבלתי נמנע של אביב בהשוואה למה שהיה במקור. עם הזמן, היה קשה מאוד לעקוב אחר כל סבך התלות באביב, והתעורר הצורך בספרייה נפרדת שתטען ותפעיל הכל בעצמה (עכשיו ה-Spring Boot האהוב שיהק איפשהו). כל הזמן הזה, JCP עבדה על דבר אחד - להשיג את הפשטות המקסימלית של כל מה שאפשר בתוך Java EE. כתוצאה מכך, ב-EJB מודרני, כדי לתאר שעועית, מספיק לציין הערה אחת מעל המחלקה, מה שנותן למפתח גישה למלוא העוצמה של טכנולוגיית Enterprise Java Beans. והפשטות דומות השפיעו על כל מפרט בתוך Java EE. כתוצאה מכך, Spring ו-Java EE הם שוויוניים בערך מבחינת פונקציונליות. יש דברים שהם טובים יותר, יש דברים שהם גרועים יותר, אבל אם אתה מסתכל גלובלי, אין הבדלים גדולים. כך גם לגבי מורכבות העבודה. גם Spring וגם Java EE הם כלים מצוינים. אולי הטוב ביותר שקיים כיום לבניית יישומי רשת ארגוניים בג'אווה. עם זאת, Java EE יכול לעבוד בדרך כלל רק בתוך שרת היישומים הארגוני (Tomcat הוא לא אחד), ואפליקציה על מחסנית ה-Spring יכולה לרוץ על כל דבר (על אותו Tomcat), ואפילו ללא שרת בכלל (שכן הוא יפעל זה בתוך עצמו באופן עצמאי). זה הופך את Spring לכלי אידיאלי לפיתוח יישומי GUI קטנים חזיתיים או ארכיטקטורות מיקרו-שירות. אך לביטול התלות בשרתי יישומים הייתה השפעה שלילית על המדרגיות של יישומי Spring. ו-Java EE מתאים היטב ליישום יישום אשכולות מונוליטי שניתן להרחבה. למפתחים המכירים את מסגרת האביב יש כיום ביקוש רב יותר בשוק העבודה. כך זה קרה מבחינה היסטורית: בתקופה שבה Java EE היה מסובך מדי, ספרינג "צבר בסיס לקוחות". ועדיין, אין תשובה ברורה לשאלה מה ללמוד Spring או Java EE. למתחיל ניתן לתת את העצה הבאה. הכירו (לפחות באופן שטחי) את שתי הפלטפורמות. כתוב פרויקט ביתי קטן גם ב-Java EE וגם ב-Spring. ואז להעמיק יותר לתוך המסגרת שתצטרך בעבודה. כתוצאה מכך, המעבר בין Spring ל-Java EE לא יהיה קשה.

תוצאות

נושא רחב היקף, כמובן, לא יכול להיות מכוסה במאמר אחד! אחרי המון מונחים חדשים, אתה כנראה רוצה "להחיל" את הידע הזה על דוגמה מהחיים האמיתיים. לכן, נמשיך ללמוד Java EE: שיעורים מעשיים על הקמת סביבה מקומית לפיתוח Java EE תמצאו במאמר הבא.