ארכיטקטורה מוכוונת אירועים
ארכיטקטורה מוכוונת אירועים היא סגנון ארכיטקטוני המגדיר ארכיטקטורת תוכנה שהיחידות הבסיסיות שלה הן אירועים. באנגלית נקראת ארכיטקטורה זו Event Driven Architecture או בראשי תיבות EDA. השימוש בארכיטקטורה זו הוא במקרים רבים בשילוב עם ארכיטקטורה מוכוונת שירותים (SOA). יש המכנים את השילוב של ארכיטקטורת EDA וארכיטקטורת SOA בשם SOA 2.0.
הישויות המשתתפות בארכיטקטורה מוכוונת אירועים הן:
- ספק אירוע (Provider) - הישות המייצרת את האירוע.
- צרכן אירוע (Consumer) - ישות המקבלת מסר על התרחשות האירוע ומידע על המופע הספציפי של האירוע. תפקידה של ישות זו הוא לנתח את האירוע ולהגיב עליו, אם נדרשת תגובה על פי המידע הכלול במסר.
בהקשר של מערכות מחשוב המשמעות של אירוע היא מידע המועבר מרכיב תוכנה אחד לרכיב תוכנה אחר ודורש מהרכיב המקבל הפעלת תוכנית.
דוגמה לאירוע הוא זיהוי ניסיון רמיה (Fraud Detection) במערכת ממוחשבת של מסחר אלקטרוני. זיהוי הניסיון הוא אירוע המחייב תגובות של רכיבי תוכנה, כגון: ביטול העסקה, הצפת פרטים מזהים של מבצע הרמיה לצורך הכללה ברשימה שחורה בתוך מערכות החברה המבצעת את המסחר האלקטרוני, דיווח לגורמי אכיפה חיצוניים וכיוצא בזה.
הגדרה
המושג אירוע הוא מושג רחב, שלא בכל המקרים מתייחס ל EDA. על מנת שאירוע יהיה חלק מארכיטקטורה מוכוונת אירועים צריכים להתקיים התנאים הבאים:
- האירוע הוא אירוע עסקי.
- הפונקציונליות העסקית, התהליכים העסקיים והאירועים העסקיים מיוצגים על ידי מערכת ממוחשבת.
- קיים אובייקט אירוע או קיימים אובייקטי אירוע - אובייקט אירוע הוא דווח המחייב פעולה. בהקשר של EDA אובייקט האירוע הוא מידע המועבר, למשל: קובץ XML.
- התנהגות הישות הצורכת את אירוע היא תגובה על אירוע. התגובה כוללת יכולת לזהות אירוע ולהגיב להתרחשותו.
עקרונות ומאפינים
להלן עקרונות מרכזיים בארכיטקטורה מוכוונת אירועים:
- אירוע הוא שינוי מצב. המונח מצב כאן הוא בהקשר של מכונת מצבים.
- ההחלטה ביחס להפעלת צרכנים נעשית באמצעות Event Handler.
- לאותו אירוע עשויים להיות מספר צרכנים.
- פעולת צרכנים שונים עשויה להתבצע במקביל, למשל: מערכת ממוחשבת השולטת בתנועות רובוט. אירוע של בקשה להרים חפץ, עשוי להפעיל בו זמנית שתי תוכניות מחשב שונות האחת מבצעת התכופפות והאחרת שולחת יד לאחוז בחפץ.
- אין צימוד (באנגלית Coupling) בין ספק האירוע וצרכן או צרכני האירוע. במקרים שקיים צימוד הצימוד הוא מינימלי.
- התרעה על התרחשות האירוע נשלחת תמיד על ידי הספק. הצרכן אינו מבצע בדיקות האם התרחש אירוע. על מנת להבטיח חוסר צימוד או צימוד מינימלי, אין לספק מידע על מהות התגובה של הצרכנים לאירוע או במילים אחרות הצרכן הוא קופסה שחורה מבחינת הספק. כמו כן דפוס ההתקשרות מצד הספק הוא ירה ושכח, כלומר: הספק אינו מקבל תגובה מהצרכן המאשרת את קבלת האירוע או את סיום הטיפול בו.
חשוב לשים לב להקבלה בין EDA ו SOA. בשני סגנונות ארכיטקטוניים אלה יש מרכיב בסיסי: שירות או אירוע. בשניהם יש ספק המיצר את השירות או את האירוע. בשתי התפיסות קיימת צמידות רפויה או צמידות מינימלית. כמו כן בשניהם מיצג המרכיב הבסיסי הממוחשב מרכיב עסקי מקביל.
השוני בין שתי התפיסות הוא ברמת הרזולוציה של המרכיב הבסיסי. מקובל לחשוב שאירוע הוא ברמת רזולוציה גסה יותר מאשר שירות. כמו כן בדרך כלל ב EDA התגובות של צרכנים שונים הן בו זמניות בעוד ב SOA הביצוע הוא בדרך כלל סדרתי.
עיבוד אירועים מורכב
בעיבוד אירועים מורכב, באנגלית (Complex Event Processing (CPE הצרכן מגיב להצטברות של מספר אירועים ולא לאירוע בודד, כך למשל: מערכת בנקאית עשויה לא להגיב לאירוע של משיכת כספים בודדת של לקוח, אבל כן להגיב למספר רב של אירועי משיכת כספים באותו יום.
גם טיפול באירועים מורכבים הוא חלק מהסגנון הארכיטקטוני של ארכיטקטורה מוכוונת אירועים. השוני הוא ביחס של רבים לרבים (M:M) במקום יחס של אחד לרבים (One to M).
ראו גם
לקריאה נוספת
- K. Mani Chandy, Schulte R., Event Processing, Designing IT Systems for Agile Companies, McGraw-Hill, September 24, 2009, מסת"ב 0071633502 / 9780071633505
קישורים חיצוניים
- Industry website on Event Processing
- Website for the Event Processing Technical Society
- WSO2 OxygenTank, Fusion: Eventing with SOA Part 2 - Eventing Using Synapse and WSO2 ESB
- Integration Consortium, Fusion: BUSINESS COMPONENT ARCHITECTURE – UNIFYING SOA AND EDA(הקישור אינו פעיל), Atul Saini
32548145ארכיטקטורה מוכוונת אירועים