מדריך למתחילים למערכות JavaBeans

Enterprise JavaBeans (EJB) עורר התרגשות רבה מאז הכרזת מרץ 1998 על מפרט Enterprise JavaBeans גרסה 1.0. חברות כמו Oracle, Borland, Tandem, Symantec, Sybase ו- Visigenic, בין היתר, הודיעו ו / או העבירו מוצרים העומדים במפרט EJB. החודש נבחן ברמה גבוהה מה בדיוק Enterprise JavaBeans. נבדוק כיצד EJB שונה ממודל הרכיבים המקורי של JavaBeans, ונדון מדוע EJB יצר עניין כה עצום.

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

על מנת להבין מדוע EJB כל כך מושך למפתחים, אנו זקוקים לרקע היסטורי כלשהו. ראשית, נסתכל על ההיסטוריה של מערכות לקוח / שרת, ועל מצב העניינים הנוכחי. לאחר מכן נדון בחלקים השונים של מערכת EJB: רכיבי EJB - החיים על מיכל EJB הפועל בתוך שרת EJB - ואובייקטים של EJB, בהם הלקוח משתמש כמעין "שלט רחוק" של רכיבי EJB. . נלך לאורך שני הסוגים של EJBs: מפגש ו יישות חפצה. כמו כן תוכל לקרוא על הבית ועל מרחוקממשקים, שיוצרים מקרים של EJB ומספקים גישה לשיטות העסקיות של ה- EJB, בהתאמה. בסוף המאמר יהיה לכם מושג כיצד ניתן לבנות שרתים הניתנים להרחבה באמצעות Enterprise JavaBeans. אבל ראשית, מבט אחורה בזמן.

היסטוריית לקוח / שרת

היסטוריה עתיקה

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

לקוח / שרת להצלה

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

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

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

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

שרתי יישומים

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

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

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

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

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

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

JavaBeans ארגוניים ושרתי יישומים הניתנים להרחבה

כעת, לאחר שבחנו קצת היסטוריה והבנו מה הם שרתי יישומים, בואו נסתכל על Enterprise JavaBeans ונראה מה היא מציעה בהקשר זה.

הרעיון הבסיסי מאחורי Enterprise JavaBeans הוא לספק מסגרת לרכיבים שעשויים להיות "מחוברים" לשרת, ובכך להרחיב את פונקציונליות השרת הזה. JavaBeans ארגוני דומה ל- JavaBeans המקורי רק בכך שהוא משתמש בכמה מושגים דומים. טכנולוגיית EJB נשלטת לא על ידי מפרט רכיבי JavaBeans, אלא על ידי מפרט JavaBeans ארגוני שונה (ומאסיבי) . (ראה משאבים לפרטים על מפרט זה.) מפרט ה- EJB קורא לשחקנים השונים במערכת הלקוח / השרת של EJB, מתאר כיצד EJB משתף פעולה עם הלקוח ועם המערכות הקיימות, מאיית את התאימות של EJB עם CORBA ומגדיר את האחריות ל את הרכיבים השונים במערכת.

מטרות JavaBeans ארגוניות

ה- EJB Spec מנסה לעמוד בכמה יעדים בבת אחת:

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

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

  • EJB שואפת להיות הדרך הסטנדרטית ליישומי לקוח / שרת לבנות בשפת Java. כמו שניתן לשלב את JavaBeans המקוריים (או רכיבי Delphi, או כל דבר אחר) מספקים שונים כדי לייצר לקוח מותאם אישית, ניתן לשלב רכיבי שרת EJB מספקים שונים כדי לייצר שרת מותאם אישית. רכיבי EJB, שהם שיעורי Java, יפעלו כמובן בכל שרת תואם EJB ללא קומפילציה מחדש. זהו יתרון שפתרונות ספציפיים לפלטפורמה אינם יכולים לקוות להציע.

  • לבסוף, ה- EJB תואם ומשתמש בממשקי API אחרים של Java, יכול לשתף פעולה עם אפליקציות שאינן Java, ותואם ל- CORBA.

איך עובדת לקוח / שרת EJB

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

הרכיב Enterprise JavaBeans

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

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

מיכל Enterprise JavaBeans

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

אובייקט EJB והממשק המרוחק

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