לא טוב היותה לבדה: על אינטגרציה של מערכות (מבוא)

ישנו שלב בחיי בניית תוכנה בו מגיע הדרישה לפיצ'ר שברור שלא סביר לבנות אותו לבד.

זה לא בגלל שבוני המערכת לא יודעים לכתוב כזה פיצ׳ר. הרבה פעמים זה גם לא עניין של מאמץ או זמן פיתוח - אלא עניינים הקשורים למשתמשים או למערכת האחרת:

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

אפילו אם תספקו למשתמש אותן סט יכולות באיכות מעולה - זה לא ישתווה לשירות אליו המשתמש רגיל.

נהוג לומר:

!If you can't beat them - join them

ואם אתם לא יכולים להחליף מערכת אחרת - כדאי שתתחברו אליה.

צורות התחברות למערכת אחרת

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


אציין את סגנונות האינטגרציה הנפוצות למערכות אחרות, מהקלה אל הכבדה:

רמה 1: הזנקת אפליקציה מרוחקת. למשל: פתיחת אפליקציה של הזמנת כרטיסים (לדף הפתיחה) מתוך האפליקציה שלנו.

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

רמה 2: שליפת נתונים חד פעמית. לדוגמה: קבלת אנשי הקשר מ LinkedIn.

רמה 3: שליפת נתונים אונליין. לדוגמה: קבלת אנשי הקשר המעודכנים, בכל רגע, מ LinkedIn.

רמה 4: עדכון נתונים חד פעמית. לדוגמה: שינוי פרטי איש-קשר ב LinkedIn.

רמה 5: סיפוק נתונים אונליין. לדוגמה: LinkedIn מציג גם את אנשי הקשר מהמערכת שלי, כאילו הם שמורים אצלם במערכת.

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

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

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

אינטגרציה של הפעלה (Invocation)

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

אפליקציית Rest שלה כפתור שמזניק את Waze. שימושי.

ברוב הפעמים מערכת ההפעלה / סביבת ריצה מספקת את התשתית לאינטגרציה ומי שמעוניין באינטגרציה צריך:

• ללמוד את הפורמט/פרוטוקול להעברת context (למשל: כתובת לניווט) לאפליקציית היעד.
• (צעד רשות): לוודא שאכן האפליקציה השנייה זמינה (כי ניסיון להפעיל אותה מבלי שהיא זמינה - עלול להראות לא טוב).

דפוס חוזר של הפעלה של אפליקציה כזו הוא decoupling by intent:

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

דוגמה אחת ל decoupling by intent יכולה להיות מערכת ההפעלה "חלונות", בה ניתן "לקשור" אפליקציה (למשל Word) לסיומת של קובץ (למשל docx.*) ואז הפעלה של הקובץ (פקודת start ב command line) תפתח את הקובץ באפליקציה הקשורה. אני יכול גם להתקין Libre Office ואז קבצי ה docx.* יפתחו בעזרת אפליקציה בשם Writer.

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

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

מנגנון  של decoupling המתבסס על כוונה (intent) מאפשר:

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

בתסריטים העסקיים שאני מכיר - decoupling by intent עשוי להיות שימושי ורב-עוצמה.

אינטגרציה של נתונים (data integration) - מושגים בסיסיים

נוהגים לחלק אינטגרציה של נתונים ל 4 סגנונות עיקריים [א]:

• אינטגרציה ע"י העברת נתונים בקובץ.
• אינטגרציה ע"י שיתוף בסיס נתונים.
• אינטגרציה ע"י קריאה מרוחקת (RPC).
• אינטגרציה ע"י שליחת הודעת (messaging / events-based).

כמו כן, פעולות האינטגרציה מתרכזות לרוב בסכמות הבאות:

• שכפול נתונים בין מערכות (Replication) או סנכרון נתונים בין מערכות. סנכרון זה מצב יותר בריא, בד"כ :)
• קיבוץ (Aggregation) נתונים ממקורות שונים למקום אחד - עבור דו"ח או Dashboard (לוח בקרה).
• הרכבה של תהליכים "עסקיים", הרכבת כמה אפליקציות פשוטות לאפליקציה מרוכבת ומועילה יותר (Business Processes). אני מדבר ב"שפה עסקית" אך זהו גם הסיפור של אפליקציית Rest שפותחת את WAZE שפותחת את גוגל (לקבל עוד נתונים בעקבות פרסומת בדרך).
• סיפוק שירותים נקודתיים, כדי למנוע שכפול נתונים או פונקציונליות - למשל שירות של מילון (Dictionary) או שירות קבלת כתובת דואר של עובד. שירותים אלו יכולים לשמש UI (כלומר: משתמש קצה) או מערכות אוטומטיות.

כן, אבל...

אם נדמה לנו שמאמץ האינטגרציה נגמר בהעברת נתונים או הזנקה של אפליקציה - אנו מעט אופטימיים.

אינטגרציות כוללות גם לא מעט קשיים בדרך:

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

ואחרי שכל האינטגרציה "הסתיימה":

• שינויים ב API / חוזה (contract) של המערכת המרוחקת.

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

אינטגרציה היא לא דבר חדש ויש Framework / מערכות לאינטגרציה, כדוגמת TIBCO (חבילת מוצרים גדולה), BizTalk של מייקרוסופט או Apache Camel (הקטן והחביב). למה לא פשוט להשתמש בהן - ולא "לשבור את הראש"?
ספריות / מערכות אלו הן כלי עזר לאינטגרציה - אך לא "פתרונות קסם" ש"מסירים מהדרך" את הבעיות הנ"ל. למשל: במקום לכתוב 100 שורות קוד בכדי להאזין לשינויים בתיקיית קבצים, לפרסר את הקובץ ולשלוח את המידע החדש שנוסף כ JMS message - תוכלו אולי לכתוב בעזרת הספריה 4-5 שורות דקלרטיביות או ב DSL שיעשו אותה עבודה. בכל זאת, לא תמצאו שם פתרונות אוטומטיים לבעיות אבטחה, הבדלי מהירות או זמינות בין המערכות וכו'. בטח שלא לבעיות של תקשורת בין בני-אדם :)
יהיה עליכם להבין את האתגרים האפשריים, לחשוב, לנתח - ולפתור.

אפרופו יש קטגוריה של פתרונות בשם ESB (קיצור של Enterprise Service Bus) - שמופיעים כמודול ברוב פתרונות ה Middleware של החברות הגדולות (IBM, Oracle, TIBCO וכו') או בגרסאות חופשיות (למשל Apache Mule).
אלו בד"כ פתרונות יותר כבדים מ"מערכות האינטגרציה" אותן הזכרתי, הם קשורים בצורה הדוקה בד"כ לארכיטקטורת SOA שמרנית, ונחשבים כלא כ"כ מוצלחים (כקונספט - אני לא מדבר על המימוש).
אני לא מנסה לדבר עליהם, ולא רוצה שתבינו בטעות שכדי לבצע אינטגרציה - זקוקים לתשתית כלשהי. כלים שכאלו כדאי להכניס לשימוש כדי לחסוך זמן (במיוחד כשיש הרבה עבודה) - לא כדי "לפתור את הבעיה".

לא קל...

תהליך אינטגרציה: ממה להיזהר? וכיצד?

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

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


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

ענייני רשת - יש לפתור נקודתית למצב הנתון.
יש כלל מנחה שאומר שאת היוזמה לתקשורת עושים מהאזור המאובטח יותר - לאזור המאובטח פחות. כך יתר קל להתמודד עם אמצעי ההגנה השונים. למשל: מן הרשת הפנימית של הארגון - לענן, או מן הרשת הפנימית של ה Data Center לרשת הארגונית ה"רגילה".
במקרים בהם אין יכולת לתקשורת ישירה (בגלל מורכבות של רשתות ה LAN בארגון) - מציבים agent או broker בדרך שיאפשר להעביר הודעות / נתונים.


עבודה בפורמטים שונים
בעוד מערכת אחת עוטפת את המידע ב XML בצורה אחת - והשנייה ב XML בצורה אחרת. עצם השימוש "המשותף" ב XML לא מוסיף לאינטגרציה כמעט דבר, אם הפורמטים שונים. גם בתוך ה XML (או JSON, CSV וכו'):מערכת אחת מתארת תאריך בפורמט ארוך - והשנייה בפורמט קצר, אחת כתובת בשדה אחד והשנייה במספר שדות שונים, וכו'.
עבור קריאות מרוחקות (RPC), ההבדלים יכולים להיות גדולים יותר: DCOM מול CORBA או RMI מול REST API - צורת התקשורת שונה, ולא רק פורמט אותו ניתן להמיר.

יש גם נושא של Data Integrity: מערכת אחת מוכנה לקבל רשומה כאשר שדה x חסר (ערך ריק) - ומערכת שניה לא מוכנה לקבל זאת. אולי תאימות בין הנתונים: מערכת אחת בודקת את ערכי השדות שיתאימו לכלל מסוים - והשנייה לא.

את המידע ממירים בעזרת Adapters (או Transformers/Normalizars במערכת מורכבת יותר) - בכדי לתאם בין הפורמטים / פרוטוקולים. לפעמים עושים תהליך נוסף של Data Quality - תיקון הנתונים בכדי לעמוד ב"סטנדרטים" של אחד הצדדים (שלמות, דיוק וכו').

עניין של פורמטים הוא בד"כ לא "נושא מורכב" (זו קרקע מצוינת לכיסוי עם Unit Tests) - אך זו עבודה. בד"כ ככל שהמידע הוא Human Friendly - ההמרה תהיה קלה יותר. המרה של מידע בינארי, נוטה להיות מורכבת יותר.


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

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


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

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

סנכרון ו concurrency

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

הבדלי מהירות / קיבולת בין המערכות

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

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

Circuit Breaker מתוך הפוסט של מרטין פאוולר בנושא.

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

מנגנון הגנה אפשרי הוא ליצור (מטאפורה:) סוג של צינור מצר, בעצם זה סוג של counting lock שלא מאפשר למערכת שלנו לבצע יותר מ x קריאות למערכת המרוחקת בו-זמנית. אנו מגנים עליה - כי זה אינטרס שלנו שהיא לא תקרוס. מנגנון כזה נקרא (Throttling (controller. כמובן שהמערכת המרוחקת יכולה לקרוס מסיבות אחרות - וזה לא תחליף ל Circuit Breaker בסיסי יותר.

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

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

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

סגנונות אינטגרציה וכיצד הם מתמודדים עם האתגרים השונים

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

אינטגרציה ע"י העברת נתונים בקובץ

אינטגרציה זו היא בסגנון export של נתונים במערכת ב' ואז ביצוע import של הנתונים אל המערכת שלנו.

יתרונות:

• "מדלגת" על מגבלות של רשת או הרשאות. ה export/import וה transport נעשים עם הרשאות של משתמשים ספציפיים.
• פשוט למימוש

חסרונות:

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

אינטגרציה ע"י שיתוף בסיס נתונים

יתרונות

• קל למימוש
• יעיל מבחינת ביצועים (גישה ל raw data)
• Consistency (יחסי) של הנתונים

חסרונות:

• אין הכמסה. מערכת אחת נוגעת במבנה נתונים של מערכת אחרת. ניתן לראות זאת כממשק מאוד מאוד רחב בין המערכות - וזו הסיבה העיקרית שגישה זו היא הכי-פחות מועדפת עלי באופן אישי, מכל הסגנונות. שינויי סכמה משפיעים מיידית על 2 המערכות.
• גישה ישירה לבסיס הנתונים עוקפת Business Logic ואימות נתונים שבא איתה, Caches של ORM או שכבות עליונות וכו'.
• בסיסי נתונים (רלציוניים בעיקר) הם מאותגרים scalability והוספת מערכת נוספת שעובדת על אותו בסיס נתונים יכולה להיות מגבילה / לדרוש שדרוג יקר של החומרה.

אינטגרציה ע"י קריאה מרוחקת (RPC)
RPC הוא קיצור של Remote Procedure Call (שם שמקורו היסטורי) והכוונה היא לכל הטכנולוגיות של הפעלת פונקציות מרחוק: REST, RMI, XML-RPC, אולי RPC ברמת מערכת ההפעלה ועוד.

יתרונות:

• הכמסה בין המערכות
• ממשק מוגדר היטב
• online

חסרונות:

• תלות חזקה בין המערכות (ממשק + ידע על מיקום/כתובת המערכת המרוחקת)
• תקשורת סינכרונית בלבד

אינטגרציה ע"י שליחת הודעת (messaging / events-based).
שליחת הודעות נעשית בד"כ דרך מנגנון לשליחת הודעות ייעודי, מה שנקרא MOM (קיצור של Message Oriented Middleware). מערכות נפוצות שבשימוש הן Apache ActiveMQ, RabbitMQ, רדיס (Redis) ומנגנון ה Pub-Sub שלו (עליו כתבתי בפוסט בעבר), Apache Kafka (ל Scale גבוה) או מימושים שונים של מנועי JEE/חברות התוכנה הגדולות.

יתרונות:

• גמישות רבה לאינטגרציות מורכבות
• פוטנציאל Scalability נהדר (בכמות הנתונים)
• אפשרות לאסינכרוניות ו reliable messaging (אולי תכונות חשובות, לא דווקא יתרונות)

חסרונות:

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

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

יש גם מרחב גדול של מימושים באמצע מבוסס REST/HTTP/JS - שזה סוג של RPC, אבל עם טכנולוגיות ווב מודרניות ופשוטות (וקצת פחות "RPC by the book")

סיכום

שוב תכננתי פוסט קצר....

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

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

נושא האינטגרציה בין מערכות תפס תאוצה מחודשת בענן. מה השתנה מעולם ה On-Premise?

יש נגישות קלה יותר ברשת והרשאות. אך שאר האתגרים נותרו פחות או יותר כפי שהיו.

אולי הדרישה לניהול מרחוק והדרישה ל"אלסטיות" של המערכות מעודדת יותר ארכיטקטורה מונחית שירותים / Micro-services? - מה שהופך את האינטגרציה לקלה יותר. לא יודע.

שיהיה בהצלחה!

----

[א] המקור המוקדם ביותר שמזכיר חלוקה זו, שאני מכיר, הוא הספר Enterprise Integration Patterns, אולם נתקלתי בחלוקה זו שוב ושוב ממקורות שונים.

Posted with Blogsy