שימוש ב- MSMQ לביצוע Decoupling מקסימלי, או איך לקבוע ארכיטקטורה מתאימה לאתגרי אינטגרציה בפיתוח מערכות בסביבת מיקרוסופט .Net - חלק ב' 

בהמשך למאמר הקודם בנושא Decoupling של מערכות אינטגרציה  תוך שימוש ב-  MSMQ (לינק), להלן דוגמא לעיצוב של מערכת אינטגרציה מורכבת, תוך התייחסות לאילוצים השונים בפיתוח מערכות בסביבת .NET מערכת האינטגרציה האמורה, משלבת בין מערכת מרכזית של ניהול עסקים באינטרנט ("מערכת א'") לבין מערכות הנהלת חשבונות ("מערכת ב'").בעיצוב (Design) המערכת נלקחו בחשבון האילוצים הבאים: 1. החיבור בין המערכות איננו קבוע (Occasionally Connected) והוא מתבצע דרך האינטרנט. כל אחת מהמערכות יכולה להיות לא נגישה/כבויה/עסוקה בפניות אחרות עם דגש על מערכת ב'. 2. כל שינוי רלוונטי במערכת א' צריך להיות מתוקשר באופן המהיר ביותר למערכת ב' ולהשתקף בה. 3. העברת הנתונים ממערכת ב' ל-א' עשויה להיות "כבדה", דהיינו תיתכן העברה של נתונים רבים בזמן קצר. 4. האינטגרציה צריכה להפריע כמה שפחות לפעילות השוטפת של המערכות. 5. קיימת חשיבות גבוהה לאמינות הנתונים בין המערכות. 6. מערכת ב' היא מערכת סגורה (של צד ג') ולא ניתן לבצע בה שינויי קוד. 7. על התקשורת בין המערכות להיות מאובטחת. 8. על ההתקנה של מערכת האינטגרציה בצד הלקוח להיות פשוטה ואוטומטית.     כדי לענות על האילוץ הראשון (חיבור לא קבוע), הרביעי (הפרעה מועטה לפעילות השוטפת) והחמישי (אמינות הנתונים), נפעל כדי ליצור אי-תלות בין המערכות, על-פי הקונספט של Decoupling במערכות אינטגרציה -  המוסבר בחלק 1 בסדרה. כדי לענות על האילוץ השני (שינויים במערכת א' צריכים להשתקף באופן המהיר ביותר במערכת ב'), קיימות שתי אפשרויות: 1. מערכת ב' תדגום (Poll) את מערכת א' כל מספר שניות/דקות/שעות מוגדר מראש – ואם קיימים שינויים, תמשוך אותם אליה.   2. מערכת א' תדחוף (Push) למערכת ב' את השינויים בזמן אמת. אפשרות הדגימה היא פשוטה יותר מבחינת המימוש. אך עלולה ליצור לחץ מאוד גדול על השרת, שכן, במידה וקיימות מערכות ב' רבות, אשר דוגמות בפרקי זמן קצרים, עלול להיווצר לחץ מאד גדול על השרת, וזאת אף אם פעולות העדכון נעשות בפועל רק אחת לכמה שעות. במערכת אותה אנו מתארים במאמר זה, החלטנו לבחור באפשרות הדחיפה (PUSH). מענה על האילוץ השלישי (העברת נתונים מאסיבית בין מערכת ב' ל-א') מתאפשר בזכות פריסה של מערכת האינטגרציה על שרת נפרד (ר' פריסה פיזית – Queue Server). כל הפעולות שתגענה ממערכת ב' תורצנה על שרת שונה מהשרת העיקרי (ה-Application Server). במקרים אלו, אמנם יכול להיווצר לחץ מסויים על מסד הנתונים, אך שרת האפליקציה יהיה חופשי לטפל בפניות אחרות של משתמשים אינטראקטיביים. מענה לאילוץ 7 (תקשורת מאובטחת בין המערכות)  מתאפשר על ידי זיהוי באמצעות שם-משתמש וסיסמא (Credentials) והצפנת SSL. בכדי לתת מענה לאילוץ 8 (ההתקנה בצד הלקוח תהיה פשוטה ואוטומטית) פותח מעין שרת תורים פשוט (Lightweight Queue) המתבסס על מסד נתונים מקומי ומנגנון FIFO בצד הלקוח (client-side). כיוון שבצד הלקוח מערכת ההפעלה יכולה להיות כמעט כל מערכת – החל מ-Windows XP Home ועד ל-Windows 2008 R2, שרת זה מפשט את תהליך ההתקנה ובעיקר מונע את הצורך להתקין MSMQ במערכות שהמתקין איננו איש IT מקצועי. עד כאן סקרנו את המענה לאילוצים השונים שעליהם ניסינו להתגבר ונתנו את תיאור המערכת באופן כללי. במאמרים הבאים, אתאר את התהליכים השונים בין המערכות את ההודעות העוברות וטיפול בתקלות.