לדלג לתוכן

Enterprise JavaBeans

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

Enterprise JavaBeans (אנטרפרייז ג'אווה בינז; בקיצור: EJB, וברבים: EJBs) היא ארכיטקטורת רכיבים לצד-שרת המשמשת ליצירת יישומי enterprise מודולריים.

המפרט של EJB הוא אחד מבין ממשקי תכנות היישומים (APIs) הנכללים במפרט של EJB .Java Enterprise Edition הוא מודל צד-שרת שתפקידו לכמס את הלוגיקה העסקית של יישום. המפרט של EJB פותח במקור על ידי חברת IBM בשנת 1997, ובשנת 1999 אומץ של ידי סאן מיקרוסיסטמס (החברה שפיתחה את Java עד שנקנתה על ידי אורקל), וממשיך להיות משופר במסגרת ה-Java Community Process. הגרסה הנוכחית היא EJB 3.1.

מטרת המפרט של EJB היא לספק צורה סטנדרטית למימוש קוד back-end "עסקי", אשר בדרך כלל נמצא ביישומי enterprise (בניגוד לקוד front-end השייך לממשק המשתמש). בדרך כלל קוד כזה מטפל בבעיות דומות החוזרות על עצמן בפרויקטים שונים, ולעתים קרובות מתכנתים מממשים מחדש את הפתרונות לבעיות אלו. מטרת ה-Enterprise JavaBeans היא לטפל בצורה סטנדרטית בבעיות נפוצות כאלה, כדוגמת: persistence, שלמות טרנזקציות (transactional integrity), ואבטחת מידע, על מנת לשחרר את המתכנתים להתרכז בפיתוח פתרונות לבעיות הספציפיות של הפרויקט.

כדי לפרוס ולהריץ Enterprise JavaBeans, ניתן להשתמש בשרת יישומים ל-Java EE אשר כברירת מחדל כולל מנגנון להרצת EJB container) EJBs). לחילופין ניתן להשתמש בקונטיינר נפרד כדוגמת OpenEJB.

שירותים עיקריים

המפרט של EJB מגדיר כיצד שרת יישומים מספק את השירותים הבאים:

כמו כן המפרט מגדיר את התפקידים של ה-EJB container וה-EJBs עצמם, ואת הדרך לפרוס את ה-EJBs בתוך הקונטיינר. המפרט העדכני, EJB 3.1, אינו מגדיר כיצד שרת יישומים אמור לספק persistence (משימה זו הועברה למפרט ה-JPA), אלא במקום זאת מפרט כיצד ניתן לשלב בקלות בין הלוגיקה העסקית לשירותי ה-persistence המוצעים על ידי שרת היישומים.

אימוץ מהיר המלווה בביקורת

חזון ה-EJB הוצג בצורה משכנעת על ידי התומכים בו כדוגמת IBM ו-Sun Microsystems, וה-Enterprise JavaBeans אומצו במהרה על ידי חברות גדולות. זמן קצר לאחר מכן התחילו להופיע בעיות בגרסאות הראשונות. חלק מהמפתחים הרגישו כי ממשקי תכנות היישומים (APIs) של סטנדרט ה-EJB היו הרבה יותר מסובכים לעומת מה שהם היו רגילים אליו. ריבוי החריגות הנבדקות (checked exceptions), ממשקים נדרשים, והמימוש של מחלקת ה-bean כמחלקה אבסטרקטית, היו חריגים ולא אינטואיטיביים עבור מתכנתים. הבעיות שבהן סטנדרט ה-EJB ניסה לטפל, כדוגמת מיפוי אובייקטי-רלציוני (ORM) ושלמות טרנזקציות, אכן היו בעיות מורכבות, אך מתכנתים רבים חשו שממשקי תכנות היישומים של EJB היו לא פחות מסובכים. זה הוביל לתפיסה ש-EJBs הכניסו מורכבות נוספת מבלי לספק שום יתרונות ממשיים.

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

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