Microsoft Word - Instructions_JavaEE_2011A_Uri_Shamay.doc

תמליל

1 פיתוח מונחה עצמים בטכנולוגיות Java/EE סמסטר א' דפי הנחיות ותרגילים מרצה: אורי שמאי דרישות הקורס בקורס אין בחינה אך חובה להגיש את כל התרגילים. שלושה תרגילים יוגשו במהלך הסמסטר, ותרגיל נוסף יוגש לאחר סוף הסמסטר. משקל התרגילים שיוגשו במהלך הסמסטר 60 נקודות,ומשקל התרגיל האחרון והמסכם 40 נקודות. ניתן להגיש את התרגילים בזוגות או ביחידים, למרות שמאוד מומלץ בזוגות. אם מבצעים את התרגיל בזוגות, על שני חברי הצוות להיות פעילים בכל התרגילים ובכל נושאיו, אם מבצעים לבד - לא יינתנו הנחות. תוכנית הקורס להלן תוכנית כללית של הקורס (עשויים להיות שינויים בסדר השיעורים): נושא מבוא לשפת Java עקרונות, תחביר וקלט פלט חריגות,(Exceptions) ספריות סטנדרטיות ויצירת מחלקות עבודה עם,Threads אוספים IO,(Collections) ו - Seriallization יסודות Application Server,Java Enterprise בסיסי נתונים בעזרת, JDBC יסודות ORM Object Relational Mapping על פי JPA 2 יסודות JPA 2 Java Persistence API Entity Beans - 2 JPA והורשה - Beans Entity ומיפוי יחסים JPA 2 יסודות JPQL Java Persistence query language יסודות EJB 3 Enterprise Java Beans המשך EJB 3 MDB Message Driven Bean && JMS API Timers,Java Mail API Web Services: Restful + SOAP מצגות J2SE J2SE J2SE שיעור

2 פניות בדואר האלקטרוני: אתר הקורס: ביבליוגרפיה: Java Tutorial: o Java EE Technologies: o Java EE 6 Tutorial: o הגשת תרגילים: הגשת תרגיל התרגילים יוגשו באמצעות מייל. התרגיל יוגש ממייל של אחד המגישים אך יש להוסיף במייל את ת"ז של המגיש השני. יש להכין קובץ zip עם כל קבצי התרגיל (למעט קבצי תמונות וקול גדולים). בהכנת קובץ ה- zip חשוב לשמור על מבנה ה- directories, כך שלמשל מחלקות של חבילה פנימית לא יפתחו לאחר מכן ב- directory הראשי. ה- source - ים אמורים לכלול תיעוד פנימי. הערות חשובות לבודק (רק אם יש כאלה) יש לרשום באופן בולט בקובץ README.TXT שישלח כחלק מה- zip (ולא כהערה ב- source, שהבודק עלול לפספס). בתרגילים הממומשים כחלק מאתר אינטרנט יש לרשום גם את ה- URL של האתר (יש לרשום URL מלא כולל.( רישום על כל סטודנט להירשם במייל mta.javaee.a2011@gmail.com בתחילת הקורס עם מילוי פרטים כלליים על הצוות. (נא לעדכן את הכתובת במקרה של שינוי) - לכתובת זו ישלחו אישורים על הגשת התרגילים,תוצאות בדיקת התרגילים,הודעות שונות) כגון הודעה על דחיית תרגיל וכו". החלפת שותף ניתן להחליף את השותף בכל תרגיל, ללא צורך באישור או הודעה למרצה. יש לדאוג בזמן שליחת מייל התרגיל למחוק את מספר תעודת הזהות של השותף הבטלן שהוחלט להיפרד ממנו. הניקוד על כל תרגיל נזקף לזכות האנשים הרשומים עליו בלבד. יש לבקש מאותו שותף, שלא ימשיך להגיש תרגילים שלו עם תעודת הזהות שלך (כי אז יבוטל התרגיל שלך, ויהיה צורך לפנות אלי לבטל את הפעולה)..3 לאחר הגשת תרגיל יש לשמור אישור לכך שהוא אכן הוגש (את הודעת הדואר האלקטרוני הנשלחת לאחר ההגשה). אם לא קיבלתם אישור בדואר אלקטרוני - התרגיל לא הוגש! בכל תקלה שהיא יש לשלוח הודעה מתאימה למרצה,ללא התרגיל עצמו.

3 כיצד להגיש תרגילים באיחור ולהישאר בחיים הגשה באיחור - יש להקפיד על הגשת התרגילים בזמן. עבור איחור של שבוע או חלק ממנו- יורדו 3 נקודות מהציון הסופי בקורס (לא מציון התרגיל). תרגיל שיוגש באיחור של יותר משבועיים ללא סיבה מוצדקת - לא ייבדק.במקרה של מחלה או מילואים ניתנת הארכה אוטומטית (גם לשותף במקרה של עבודה בצוות),ואין לפנות בבקשת דחייה.יש למסור את האישור למרצה (למילואים טופס שחרור ולא צו קריאה) לאחר הגשת התרגיל,ולציין על האישור איזה תרגיל הוגש באיחור (אם הורדו נקודות הן יוחזרו). אם נסמן ב- Xi את מספר הימים שחבר הצוות i היה חולה או במילואים (או גם וגם) ההארכה שתינתן היא (X2 max(x1, ימים. הארכה תינתן רק לרצף ימי מילואים או מחלה שלפחות חלקו הוא בתקופה שבין 30 יום לפני הגשת התרגיל ועד ליום הגשת התרגיל (ובמקרה זה כל רצף הימים יחשב לצורך ההארכה). חתונה של מגיש התרגיל בתוך 30 יום לפני מועד הגשת התרגיל,נחשבת כמו מילואים (או מחלה) של שבועיים. כמעט בכל בעיה אישית אחרת (שאינה מחלה,מילואים או חתונה),כגון לחץ בעבודה, נסיעה לחו"ל,מעבר דירה,מועדי ב,'מועדי ג,'מועדי ד, פטירתה בטרם עת של הסבתא רבא,חתונה של קרוב משפחה קרוב (הסבא רבא האלמן),וכו" - לא תינתן הארכה.מה שאפשרי במקרים אלו זו בקשת הקלה בקנס.הפרוצדורה לבקשת הקלה היא פניה ב עם תיאור הבעיה לאחר שהתרגיל הוגש.כל בקשת הקלה תיענה (אם אכן נשלחה לאחר הגשת התרגיל), והקנס המקסימאלי במקרה זה יהיה 2 נקודות לשבוע איחור.יתכן כמובן קנס נמוך יותר אם הסיבה משכנעת,אך ברוב המקרים צפוי קנס כלשהו. נא להקפיד על ההנחיות הבאות: בכל נא לציין שם פרטי ושם משפחה,מספר ת"ז,ובאיזה מכללה אתם לומדים. בתגובה לתשובה שלי - נא לכלול את הטקסט שלי (כדי לסייע לי לזכור במה מדובר ). במקרה של שאלה בנושא exception חובה לצרף stack trace מלא.במקרה של שאלה בנושא שגיאת קומפילציה חובה לצרף את הודעת השגיאה.ניתן לכתוב את ה- בעברית או באנגלית אבל לא במסמך מצורף (כגון מסמך.(Word ערעור על בדיקת תרגיל נא לשלוח קודם כל לבודק התרגילים במייל בלי CC אלי.נא לערב אותי רק אם עברו שבועיים ולא התקבלה תשובה מהבודק,או כשתשובת הבודק לא פותרת את הבעיה לשביעות רצונכם. אישורים על מילואים ומחלה אפשר לשלוח לי ב- רק כאשר גודל הקובץ הסרוק הוא עד 1MB (לאחר דחיסה). אחרת יש לשים עותק של האישור בתא שלי במכללה. אם לא קיבלתם תשובה תוך 48 שעות סביר להניח שה- לא הגיע אליי (למשל לפעמים -ים מ- Walla מסוננים בדרך) או שהתשובה שלי אבדה בדרך אליכם. לא תתקבל כל טענה בדבר או הבטחה שקיבל סטודנט ביחס לדרישות הקורס או התרגילים ללא גיבוי בכתב (או בדואר אלקטרוני) מהמרצה. אם קיבלתם הקלה או הבטחה בע"פ שילחו את סיכום הדברים ב אלי, ושימרו את ה- החוזר עם האישור, עד לקבלת הציון הסופי בקורס. בכל מקרה שאין אישור כנ"ל בכתב הכול יתבצע רק ע"פ ההוראות בדפי הנחיות אלו.

4 דרישות כלליות לכל התרגילים חובה להקפיד על סגנון כתיבה ראוי. יש להימנע משכפול קוד, מפונקציות ארוכות מדי ומבחירת שמות גרועים למחלקות לפונקציות ולמשתנים. יש להקפיד על מוסכמות בסגנון הכתיבה שמות מחלקות יתחילו באות גדולה, שמות משתנים ופונקציות באות קטנה, שמות קבועים יהיו מורכבים רק מאותיות גדולות, יש להקפיד על indentation נכון, וכו. יש להקפיד להשתמש ב- modifiers בצורה נבונה. מחלקה שלא אמורים לבנות אובייקטים שלה אמורה להיות מוגדרת כ- abstract, קבועים יש לסמן כ- final, משתני מופע רצוי כמעט תמיד להגדיר כ- private, וכו. לפני כל מחלקה ולפני כל פונקציה חובה לרשום תיעוד קצר בפורמט של.JavaDoc חובה לבצע תקינות לכל קלט של המשתמש, ובמקרה של קלט שגוי לטפל בעזרת.(stack trace מתאים אם הודעה מתאימה (לא exception יש לדאוג שבאף מקרה לא תיזרק Exception לא מטופלת שתעצור את התוכנית בהדפסת מסביב ל- main Throwable של כללי אך מצד שני יש להיזהר מ- catch stack trace שיקשה על תחזוקת התוכנית וזיהוי באגים. הערה: ניתן להיעזר Java Code Conventions באתר הבא: הערה כללית :חלק מהעבודה בתרגילים היא קבלת החלטות בנושאים שאינם מפורטים במדויק.המטרה היא לתרגל את הנושאים המרכזיים הנלמדים בקורס,ולא לתפור מוצר לפי דרישות של לקוח,ולכן בכל מקום שלא מופיעה דרישה מדויקת מוטל עליכם לבחור בדרך ההגיונית ביותר שנראית לכם.

5 תרגילים מערכת לניהול הזמנת מוצרים התרגילים עוסקים בנושא משותף, מערכת לניהול הזמנת מוצרים, כאשר כל תרגיל מוסיף פונקציונאליות למערכת. דרישות התרגילים אינן כוללות פיתוח ממשק משתמש גרפי (שכן זה אינו חלק מנושאי הקורס) ולכן כל התרגילים ימומשו ע"י תכנית Console רגילה. לתשומת לבכם, ייתכנו שינויים קטנים בתרגיל במהלך בקורס (כמו פירוט נוסף על דרישה קיימת, עדכון/שינוי/הורדה של דרישה וכו'). במידה ויהיו שינויים כאלה, העדכונים יינתנו בכיתה ויעודכנו באתר. על אחריות התלמיד לוודא את פרטי התרגיל המעודכנים ביותר. בקורס יינתנו 4 תרגילים כאשר שלושה מהם להגשה במהלך הסמסטר והאחרון להגשה כחודש לאחר סיום הלימודים. הערות: 1. עיצוב התוכנית נתון להחלטתכם, הישויות במערכת שצוינו הם רק לצורך המחשה של המערכת בצורה כללית, ניתן להחליט על מיקום המאפיינים בצורה חופשית וכמו כן על צורת הגדרת היחסים בין האובייקטים השונים, כלומר האם קיים יחס חד/דו כיווני בין האובייקטים. 2. בעיצוב התוכנית צריך להתייחס לכך שמספר הקטגוריות יגדל בעתיד 3. ניתן להניח כי קיים משתמש Administrator כברירת מחדל במערכת מבעוד מועד 4. משתמש Administrator לא יכול למחוק את עצמו. 5. יש לתת הודעה ברורה למשתמש על כל פעולה שנכשלה מכל סיבה שהיא או על כל פעולה שהצליחה להיכתב בהצלחה. 6. משתמש Administrator יכול לבצע כל פעולה שמשתמש Read/Write מסוגל לעשות 7. לא צריך לדאוג לסנכרון בין התוכניות כאשר התוכנית הראשית מתרגיל 1 מורצת מספר פעמים 8. מאפיינים שצוינו כ: (UNIQUE) מציינים ייחודיות, כלומר לא ניתן ליצור ישות חדשה כאשר כבר קיימת ישות עם המציין הייחודי. 9. מהתפריט של משתמש Read Write המשתמש יכול ליצור אך ורק משתמש Read Only (ולשייכו להזמנה קיימת שלו). על מנת לייצר משתמש Read Write נדרש לחזור לתפריט הראשי של המערכת. 10. כאשר מוצר נמכר למשתמש, המערכת מעדכנת את הכמות של המוצר בהתאמה, כאשר הכמות מגיעה לאפס המוצר לא נמחק מהמערכת. 11. בכל רגע נתון בתוכנית, המערכת צריכה לספק אפשרות לחזור לתפריט הקודם + לתפריט הראשי + ליציאה סדירה מהתוכנית עם הודעה מתאימה. 12. בכל פעולה של חיפוש איבר באחד ממבני הנתונים השונים, אם החיפוש מתבצע על פי מאפיין שהוא לא ייחודי הערך המוחזר יכלול את סך האיברים המתאימים. 13. נדרש להזין שם משתמש וסיסמא על מנת לבצע פעולות במערכת, מלבד פעולה של יצירת משתמש Read Write שניתן לעשות בתפריט הראשי. 14. למען הנוחות בתרגיל 1, ניתן בזמן טעינת התוכנית לטעון את כלל מבני הנתונים מהקבצים השונים, ושמהלך התוכנית יהיה אל מול מבני הנתונים בתוכנית עבור כלל הפעולות, ובזמן יציאה מהתוכנית לדרוס את הקבצים השמורים עם מבני הנתונים המעודכנים. 15. לא ניתן למחוק משתמש שיש עבורו הזמנות פעילות

6 16. על מנת לא ליצור קונפליקטים שהועלו בכיתה לא ניתן למחוק מוצר/הזמנה מהמערכת נקודות) 20) המערכת וממשק משתמש בסיס 1 תרגיל תאריך הגשה: במסגרת תרגיל זה נציב את היסודות למערכת לניהול הזמנת מוצרים. מטרת התרגיל לתכנן ולעצב את מבני הנתונים, הישויות והקשרים הדרושים למערכת. תרגיל זה כולל את רוב ממשק המשתמש, כלומר את מימוש התפריטים המנווטים את המשתמש במהלך השימוש במערכת. בתרגיל זה נממש את הנתונים כמחלקות Java רגילות, כמובן בתוספת שימוש בהורשה ותכונות תכנון מונחה עצמים נוספות. בתרגיל זה הנתונים יישמרו לקבצים ע"י שימוש ב- Serialization של אובייקטים. בתרגיל זה נדרש לממש את פונקציות קלט הנתונים מהמשתמש ופונקציות ההדפסה למסך. בנוסף, כל הישויות הנדרשות בתרגיל (כגון מוצר, משתמש וכ"ו) יישמרו לאוספי נתונים (ניתן להשתמש באחד מהאוספים (Collection) של (java שיישמרו בסוף התכנית לקבצים רלבנטיים. כל שירותי חיפוש איבר, מחיקת איבר וכו' יתבצעו ע"י פונקציות שירות הנתמכות ע"י האוסף. ישויות נתמכות מערכת לניהול הזמנת מוצרים אמורה להכיר לפחות את הישויות הבאות: משתמש: שם משתמש,(UNIQUE) מזהה - מספר רץ, שם פרטי, שם משפחה, סיסמה,,(UNIQUE) תאריך יצירה,גיל,רשימת הזמנות (כולל דואר אלקטרוני (UNIQUE) ת,.ז היסטוריה), הרשאות: a. Read Write Access User.i Read Only Access User.ii Administrator.iii מוצר: שם,(UNIQUE) מק"ט משרד, בית,(UNIQUE) מחיר, כמות, קטגוריה: אלקטרוניקה, רכב, (UNIQUE) מספר רץ, מזהה שם משתמש, תאריך ביצוע, תאריך הזמנה: מספר הזמנה מיועד למשלוח, מחיר סך ההזמנה, רשימת מוצרים צורת מסירה: a. ידנית i. משלוח.ii סטאטוס: b. הזמנה חדשה i. ממתינה במקרה שחסרים מוצרים במלאי.ii מוכנה למסירה.iii במשלוח.iv בוצעה v..3 קטגוריה: מזהה קטגוריה (UNIQUE) מספר רץ, שם קטגוריה,(UNIQUE) רשימת מוצרים בקטגוריה a. הערה: סוגי קטגוריות - אלקטרוניקה, רכב, משרד, בית.4

7 תכנון ישויות וקשרים כחלק מעיצוב המערכת יהיה עליכם לתכנן/להוסיף ישויות במקרה הצורך. תכנון מבני הנתונים והקשרים ביניהם הם חלק מההחלטות הנדרשות בתרגיל זה. עליכם לבחור את הדרך הנכונה ביותר לעיצוב התוכנה עפ"י פונקציות המערכת הנדרשות. שירותי המערכת במערכת לניהול הזמנת מוצרים נדרשות הפעולות הבאות: פעולות Administrator ניהול מלאי המוצרים a. הוספה של מוצר i. חיפוש מוצר.ii על פי מק"ט 1. על פי שם 2. על פי מחיר 3. על פי שם קטגוריה 4. עדכון מוצר.iii הדפסה של פרטי מוצר.iv ניהול שירות הלקוחות b. הוספה של משתמש חדש למערכת i. עדכון פרטי משתמש קיים.ii מחיקת משתמש מהמערכת.iii חיפוש משתמש.iv על פי שם פרטי/שם משפחה 1. על פי דואר אלקטרוני 2. על פי ת.ז 3. על פי מזהה משתמש 4. הדפסת פרטי משתמש v. ניהול הזמנות c. עדכון סטאטוס הזמנה i. הנפקת דוחו"ת שונים d. הדפסת כל המשתמשים במערכת i. (כולל רשימת ההזמנות הנוכחית מסוים משתמש הדפסת פרטי.ii וההיסטורית) הדפסת כלל ההזמנות.iii הדפסת כלל ההזמנות על פי סטאטוס.iv הדפסת כלל המוצרים v. הדפסת כלל המוצרים במערכת ממוינים בסדר עולה על פי מחיר.vi הדפסת כלל המוצרים על פי קטגוריה.vii

8 הדפסת כלל הקטגוריות הדפסת מספר המוצרים בכל קטגוריה הדפסת כלל המוצרים על פי מחיר (לדוגמה כל המוצרים שמחירם גדול/קטן מ 1,000 ש"ח) חיפוש מוצר והדפסה של מספר המשתמשים שהזמינו אותם היסטורית הדפסה של המוצר הנמכר ביותר.viii.ix.x.xi.xii פעולות User יצירת משתמש Read Write Access חדש במערכת a. עדכון פרטי משתמש במערכת (לא ניתן לעדכן את רשימת ההזמנות) b. יצירת הזמנה c. יצירת משתמש Read Only Access ושיוכו לצפייה בהזמנה d. הערה: משתמש לא יכול ליצור משתמש Read Only Access ללא שיוך i. להזמנה קיימת שלו נקודות) 20) ב ב- persistence תמיכה 2 תרגיל תאריך הגשה: בתרגיל זה נרחיב את המערכת כך שתשמור את נתוניה למערכת מסד נתונים.(database) עליכם להמיר את כל המחלקות לישויות מסוג.Entity Beans שימו לב למימוש סוגי קשרים נכונים one-to-many) one-to-one, וכו') ומימוש הורשה נכונה. בתרגיל זה נדרש להסיר את השימוש ב- Collection שהיו בתרגיל 1. טבלאות ה- DB מהוות מעתה בסיס הנתונים שאליו נשמרים הנתונים. עליכם להגדיר את ה- DB בצורה נכונה ולהמיר את כל העבודה עם הנתונים (יצירה, עדכון, מחיקה, חיפוש) לעבודה עם.JPQL התוכנית תמומש ע"י J2SE application שתשתמש בספריות JPA 2.0 ו - DB.(javadb) Derby

9 נקודות) 20) EJB 3 - ו Enterprise Application 3 תרגיל תאריך הגשה: המרה ל- Application Enterprise בתרגיל זה נמיר את המערכת ל- Application Enterprise ונחלק אותה לשני מודולים מרכזיים: תוכנת שרת Side EJB Module Server במודול זה יהיו מוגדרים ה- Entities השונים, ממנו תיעשה כל עבודת ה- DB ובו יתבצע ניהול הנתונים מול בסיס הנתונים. תוכנת לקוח Side Enterprise Application Client Client מודול זה אחראי על ניהול הקלט והפלט של התכנית. מודול זה אחראי על קליטה ועל הצגה של הנתונים השונים. עבודה עם EJB 3 עליכם להמיר את שירותי המערכת השונים כך שימומשו כ- Beans /Singleton/Stateless) Session Stateful לפי הצורך). כלומר, כל שירותי המערכת ימומשו כשירותים של Bean עפ"י חוקי עבודה עם Session Beans בגרסה.3 בנוסף, עליכם לתמוך בעבודה עם (Message Driven Bean) MDB לקבלה וניתוח של הודעות א- סינכרוניות. מערכת לניהול הזמנת מוצרים עובדת עם חברה שבונה עבורה את קטלוג המוצרים. חברת הקטלוג שולחת למערכת שלנו הודעות JMS שמכילות פרטים על קטגוריות חדשות וכמו כן למוצרים חדשים. בתרגיל עליכם לתמוך בפונקציונאליות הבאה: עליכם לממש את תוכנת חברת הקטלוג, אשר בעזרת,JMS API תשלח את ההודעה עם ההצעה החדשה לקטגוריה או למוצר חדש למערכת ניהול המוצרים שלנו. בנוסף, עליכם להרחיב את הפרויקט ולממש (MDB) Message Driven Bean מתאים שיאזין ל- queue הרלבנטי ויקבל הודעות אלה. בעקבות המידע שהתקבל מחברת הקטלוג, תבנה מערכת לניהול מוצרים ישות מסוג קטגוריה/מוצר חדש ותוסיף אותו למלאי המערכת. בעקבות ההוספה הקטגוריה/המוצר יהיה זמין ללקוחות לצפייה בפרטיו ולהזמנתו. תוכנת חברת הקטלוג תמומש כאפליקציית Enterprise Application Client נפרדת (שכמובן תהיה בעלת הקונפיגורציה הנכונה על מנת שתהיה מסוגלת לשלוח הודעות ל- queue שהוגדר במערכת לניהול מוצרים). עליכם להגדיר את התור (queue) הרלבנטי שינוהל ע"י מערכת לניהול מוצרים ואשר ימתין לקבלת ההודעות. הגדרה זו נעשית ע"י.Application Server Admin Console ** על מנת לאפשר בדיקה נוחה עליכם להגדיר את משאבי ה- JMS הרלבנטיים בשמות קבועים: ה- Connection Factory ייקרא jms/ordercatalogfactory ה- Destination ייקרא jms/ordercatalogqueue

10 נקודות) 40) מסכם תרגיל 4 תרגיל תאריך הגשה: בתרגיל זה נממש: חשיפת WEB SERVICE API למשתמשים חשיפת WEB SERVICE API למנהל המערכת ניהול מערכת התרעות אוטומטית.3 הערות: כל פונקציה ב SERVICE WEB תקבל פרמטרים נוספים של שם משתמש וסיסמא, אם שם המשתמש והסיסמא שגויים תיזרק חריגה מתאימה למשתמש..Stateless Session Bean ימומש כ WEB SERVICE API WEB SERVICE API עבור משתמשים ועבור מנהל המערכת אמורים להיות מוגדרים ב - Bean Stateless Session שונים. חשיפת WEB SERVICE API למשתמשים: פונקציות: רשימת כלל המוצרים במערכת רשימת ההזמנות שעוד לא יסתיימו עבור משתמש יצירת הזמנה.3 חשיפת WEB SERVICE API למנהל המערכת: פונקציות: 1. הנפקת כלל הדוחות במערכת ניהול מערכת התרעות אוטומטית: פונקציונאליות מערכת ההתרעות האוטומטית: תודיע למשתמשים באופן אוטומטי מה סטאטוס ההזמנה שלהם a. ביצוע סריקה יומית (כל יום בשעה (GMT 08:00 של כלל ההזמנות שעוד לא הושלמו, ושליחת מייל אוטומטי למשתמשים בהתאמה, על המייל להכיל את פרטי ההזמנה. תודיע למנהל המערכת מה המוצר הפופולארי ביותר וכמו כן את המוצר הכי פחות פופולארי a. ביצוע סריקה יומית (כל יום בשעה (GMT 23:59 של כלל ההזמנות החדשות שבוצעו ביום ספציפי, ושליחת מייל אוטומטי למנהל המערכת שיכיל את המוצר הפופולארי ביותר וכמו כן את המוצר הכי פחות פופולארי שבוצעו באותו יום אם הכמויות בהתאמה..A.B

11 הסריקות היומיות שלעיל ימומשו בתוך.Session Bean Stateless בכדי לאפשר שליחה של מיילים, עליכם לקלוט כתובת אי-מייל שתשמש ככתובת המקור של כל המיילים, את כתובת האי-מייל שנבחרה עליכם לשמור בבסיס הנתונים שישמש את המערכת בכל פעם שנדרשת שליחה של מייל. עליכם להגדיר את שירות המייל ע"י.Application Server Admin Console ** על מנת לאפשר בדיקה נוחה עליכם להגדיר את משאב ה- Session JavaMail בשם: OrderSystemMail עליכם לספק מודול של Enterprise Application Client שיכלול: פונקציה שמשמשת כ - CLIENT WEB SERVICE עבור בדיקה של כלל הפונקציונאליות של ה API WEB SERVICE למשתמשים פונקציה שמשמשת כ - CLIENT WEB SERVICE עבור בדיקה של כלל הפונקציונאליות של ה API WEB SERVICE למנהל המערכת בהצלחה!