מצב תוכנת הביניים של יישומי Java, חלק 1

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

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

זוהי הראשונה מתוך סדרת מאמרים דו-חלקית המוקדשת להסברת תוכנת התווכה הכללית של ג'אווה למגוון צורותיה הנוכחיות. במאמר ראשון זה אבחן את התכונות של המוצרים הנוכחיים ואסביר מדוע תכונות אלה חשובות. בחלק השני, Anil Hemrajani יבחן את Enterprise JavaBeans (EJB) ויראה כיצד הדור הנוכחי של מוצרי Middleware Java מתייחס ותומך בתקן מרכיב חשוב זה.

רקע כללי

קודם כל, בואו נגדיר את תוכנת הביניים של Java.המונח כולל שרתי יישומים כמו BEA WebLogic, מוצרי העברת הודעות כמו ActiveWorks של Active Software ו- SpiritWAVE של Push Technologies, ומוצרים היברידיים הבונים על מורשת DBMS ומוסיפים תכונות ביצוע אובייקט Java מבוססות שרת. יכולתי להתמקד בקטע צר יותר, כמו שרתי יישומים, אך זה היה לא הוגן כלפי המוצרים הרבים שאינם מתאימים לקטגוריה זו באופן מדויק, אך עם זאת יש לשקול אותם ליישומים רב-שכבתיים. יתר על כן, גם בקרב שרתי יישומים יש די ספקטרום, כולל כאלו שהם בעיקר שרתי servlet וגם כאלו שמבוססים על ORB או OODB. מתיחת קו בין כל המוצרים הללו מתגלה יותר ויותר קשה. עם זאת, התכונה המאחדתהיא שכולם מנסים לפתור את בעיית פריסת היישומים הרב-תכליתיים באמצעות טכנולוגיות Java ואינטרנט.

המקרה העסקי להשתמש בג'אווה בתוכנות ביניים משכנע; בין היתרונות שמציעה תוכנת הביניים של Java הם:

  • היכולת של האינטרנט לקשר בין משרדים וארגונים כלכלית

  • הצורך בארגונים לשתף פעולה על ידי שיתוף נתונים ותהליכים עסקיים

  • הרצון לאחד שירותים גנריים וניהול שירותים אלה

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

  • הרצון להשתמש בשירותים ופרוטוקולים פתוחים

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

  • הצורך לתמוך ביישומי ארכיטקטורה מעורבת בשיתוף פעולה

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

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

  • הרצון למנף מומחיות מונחית עצמים על ידי הרחבתה לתחום השרתים - ומכאן מוצרי שרת מוכווני עצמים חדשים יותר וגשרים בין אובייקטים להתייחסות.

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

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

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

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

יעדים לתוכנת ביניים

תקן רכיבי התיווך EJB פותח עם היעדים הבאים:

  • כדי לספק יכולת פעולה הדדית של רכיבים. שעועית ארגונית שפותחה עם כלים שונים תעבוד יחד. כמו כן, שעועית שפותחה עם כלים שונים תפעל בכל סביבת EJB.

  • לספק מודל תכנות קל לשימוש תוך שמירה על גישה לממשקי API ברמה נמוכה.

  • לטיפול בבעיות מחזור החיים, כולל פיתוח, פריסה וזמן ריצה.

  • לספק תאימות לפלטפורמות קיימות, המאפשרת הרחבת מוצרים קיימים כדי לספק תמיכה ב- EJB.

  • כדי לשמור על תאימות עם ממשקי API אחרים של Java.

  • כדי לספק יכולת פעולה הדדית בין יישומי EJB ולא-Java.

  • כדי להיות תואם ל- CORBA.

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

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

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

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

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

  • זה אמור לאפשר למנהלי מערכות לבצע בחירת רכיבי תשתית מבלי להשפיע על יישומים, ולכוונן ולגדול את הרכיבים הללו ויש להם אמצעי אחיד וגנרי למדידת ביצועי ומשאבי הצרכים של כל היישומים.

  • זה אמור לאפשר העברת רכיבים עסקיים בין לקוחות לשרתים מבלי להשפיע על האדריכלות של אף אחד מהם

  • זה אמור לספק מנגנון אבטחה המאפשר למשתמשים מסוימים להוסיף רכיבים חדשים, מבלי לתת למנהל השרת גישה לכל הרכיבים ומקורות הנתונים (זו הזדמנות נהדרת ליכולת ערך מוסף, מכיוון שהיא קריטית ליישומי חוץ-רשת ושותפות. )

רכיבים ותכונות של פלטפורמות התווכה של Java

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

מודלים של אובייקט, רכיב ומיכל

רכיבי יישומים חייבים לדבוק במודל פריסת זמן ריצה כלשהו, ​​המפרט כיצד הרכיב מתקשר עם סביבתו; (יתכן) כיצד הוא מותקן, התחיל, עצר והתקשר אליו; וכיצד הוא ניגש לשירותים החשובים לסביבתו. דגמי זמן ריצה ומכלים פופולריים של רכיבי שרת הממוקדים ב- Java כוללים RMI, EJB, CORBA, DCOM, servlet, JSP (דפי שרת Java) ו- Java המאוחסנים. בנוסף, דגמי הרכיבים יכולים לבוא לידי ביטוי במגוון שפות בסיסיות, כולל Java, IDL, C ++, ורבות אחרות.

יש חפיפה עם דגמי רכיבים שונים. לדוגמא, RMI הוא מודל רכיב טריוויאלי עם מתקנים בסיסיים מאוד להפעלת ומיקום אובייקטים, והוא בעיקרו תקן קריאה מרחוק, ואילו EJB ממנף את RMI ומציין את RMI כמודל קריאת האובייקטים העיקרי שלו. EJB תומך גם ב- CORBA. למעשה, אף אחד מהדגמים הללו אינו בלעדי, ושרתי יישומי Java רבים תומכים ברוב או בכל הדגמים שלמעלה.

שרתי תוכנת אמצעי תיווך רבים של ג'אווה מריצים מספר מקרים של אובייקטים עסקיים (שכיום קורב עולם ה- CORBA) בתוך מכונה וירטואלית אחת של Java (JVM). בטיחות הסוג של שפת ג'אווה מאפשרת לתהליך JVM יחיד לבצע בקשות שירות ממספר לקוחות ולהשתמש במבני נתוני התוכנה ובמעמיסי מחלקות כדי לשמור על הפרדת נתוני הלקוח. כל עוד משרתים לא מעסיקים שיטות מקומיות משלהם, לא ייתכן שמשרת אחד מביא משרתים אחרים למטה אם הוא מתרסק (אלא אם כן הוא נתקל בבאג ב- JVM עצמו), או לגשת לנתונים שהם פרטיים לשיעורים אחרים. . שרת עצמים שתוכנן כראוי יגן על האובייקטים הפרטיים שלו וימנע מאובייקטים שגויים לגשת אל מה ששייך לאובייקטים אחרים.

עם זאת, נתונים המוצהרים כסטטיים בשיעור Java ניתנים לשיתוף בין לקוחות בתוך אותו JVM אם הלקוחות משתמשים באותו מטעין מחלקה, ולכן יש להגדיר כללים שיכתיבו מתי JVM נפרד (או שווה ערך ל- JVM נפרד המשתמש בזיכרון- יש צורך בטכניקות חלוקה) או מטעין כיתה נפרד בכדי להעניק ללקוח שטח נתונים סטטי משלו. כללים כאלה נקבעו עבור יישומונים, אך לא עבור סביבות ביצוע אחרות. שרת האינטרנט של ג'אווה של Sun משתמש ב- JVM יחיד עבור כל ה- servlets ובמרחב שם כיתה נפרד עבור servlets עם בסיס קוד שונה. EJB עוקף את הנושא בכך שהוא אוסר על נתונים סטטיים לא סופיים.

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

תאימות EJB (גרסה)

מודל EJB כבר נהיה תומך אוניברסלי. כמעט כל ספק אמצעי תוכנה הבטיח לתמוך בכך ורבים כבר עושים זאת. יתר על כן, קבוצת ניהול האובייקטים (OMG) שילבה מיפוי ל- EJB כחלק ממפרט רכיבי CORBA המוצע . קשה לדמיין שאפילו מיקרוסופט, ההחזקה הבודדת והיציבה, לא תניב בסופו של דבר ותספק מכולות EJB עבור DCOM.

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