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

ארכיטקטורה
שלושה אתגרים עמדו לנגד עיני כשעסקתי במימוש פיתרון האינטגרציה:
1. ניתוק פיזי ואי-תלות בין המערכות (decoupling) - בכדי למנוע כל תלות אפשרית. למשל, שבעיות תקשורת או עומסים במערכת אחת לא יפריעו למהלך התקין של שתי המערכות.
2. ביצועים (Performance), או יותר נכון, אי-פגיעה בביצועים - התקשורת בין המערכות תיצור פגיעה מינימלית בביצועיהן.
3. אבטחת מידע (Security) - על הנתונים בין המערכות להשאר חסויים (מידע רפואי וכו'). במאמר לא אעסוק בנושא זה, אם כי ברור שעסקנו בו רבות מהתכנון דרך המימוש ועד לבדיקות.

בכדי להשיג אי-תלות בין המערכות, השתמשנו ב-MSMQ, בשלושה תורים. תור ביניים (Intermediate) - הודעות הממתינות לקריאה ע"י מערכת האינטגרציה; הודעות יוצאות (Outgoing) - הודעות הנשלחות ע"י המערכת שלנו למערכת חיצונית; הודעות נכנסות (Incoming) - הודעות המתקבלות במערכת שלנו ממערכת חיצונית.
ע"י השימוש ב-MSMQ אנחנו משיגים, למעשה, 3 מטרות. הראשונה, כתוצאה מעבודה א-סינכרונית מול התורים, קיימת פגיעה מינימלית ביותר בביצועים. השניה, אם שרת האפליקציה של מערכת א' עסוק (או אפילו כבוי), עדיין מערכת ב' יכולה לשלוח הודעות. האחרונה, חשובה לא פחות, תקשורת בכיוון השני. כלומר, תקשורת בין המערכת שלנו למערכת הלקוחות החיצוניים. במידה ומערכת חיצונית לא מגיבה, ההודעות יישארו בתור ההודעות היוצאות עד שהתקשורת בין המערכות תתאפשר שוב.
פריסה לוגית

ישנם שלושה תהליכים (Processes) המשתתפים באינטגרציה:
1. ASP.NET - האפליקציה עצמה. בדרך כלל תרוץ על שרת אפליקציה תחת IIS.
2. Windows Service - שירות חלונאי, שתפקידו למשוך (על-ידי polling) הודעות משרת התורים (MSMQ), לעבד אותם ולהעביר אותם הלאה, פנימה או החוצה. רצוי שתהליך זה ירוץ על שרת נפרד לשם הורדת עומסים, חלוקת סיכונים והורדת תלות בין התהליכים.
3. קיים עוד תהליך אחד, שלמעשה יכול לרוץ כחלק מה-IIS, והוא השירות (Service) שמקבל הודעות ממערכות חיצוניות - זהו במקרה שלנו, שירות WCF Windows Communication Foundation, אשר הינו חלק מתשתית ה- .NET ומאפשר בניה מואצת של אפליקציות המבוססות שרותים (כפי שניתן לראות בלינק המצורף: http://msdn.microsoft.com/en-us/netframework/aa663324.aspx), אשר מקבל הודעות ומעביר אותן לתור ההודעות הנכנסות (Incoming Queue).

התהליכים:
הוצאת הודעות
הודעה נוצרת ע"י המערכת (מתוזמנת ו/או אוטומטית) או משתמש, כתוצאה מתהליכים מסויימים אשר קורים במערכת, בשכבת ה-Business Process. ההודעה נשלחת ל-Intermediate Queue, תור ביניים, אשר תפקידו להוציא אותה כמה שיותר מהר, או למעשה, "לזרוק" אותה מהמערכת.
Windows Service מושך את ההודעה מה-Intermediate Queue ומעביר אותה ל-OutboundProvider, לצורך ניתוח ותרגום למבנה "אובייקטיבי", המתאים למערכת האינטגרציה. מכאן, ההודעה נשלחת ל-OutboundQueue. מתוך ה-OutboundQueue ההודעה נמשכת ע"י ה-OutboundAdapter אשר לו יש שני תפקידים: האחד, להפוך את ההודעה למתאימה למערכת החיצונית (למערכות חיצוניות שונות יכולים להיות Outbound Adapters שונים), והשני, לשלוח את ההודעה למערכת החיצונית - ע"י WCF - לצורך מהירות, אבטחה ושמירה על סטנדרטים.

קבלת הודעות
קבלת ההודעות יכולה להתבצע בדרכים שונות, כגון, קבצים, web services, WCF services וכד'. ה-Incoming Adapter נותן את הממשק המתאים למערכת החיצונית וכמו ה-Outbound Adapter, גם המימוש שלו תלוי במערכת ממנה אנו מקבלים את ההודעות. כשנכנסת הודעה, ה-Incoming Adapter מתרגם אותה להודעה "אובייקטיבית" אשר מוכרת ע"י מערכת האינטגרציה ושם אותה ב-Incoming Queue.
ה-Incoming Manager, חלק מה-Windows Service, קורא את ההודעה הנכנסת, ומעביר אותה ל-Incoming Provider, אשר מתרגם את ההודעה ה-"אובייקטיבית" להודעה שהמערכת העסקית מכירה. לאחר מכן, ההודעה נשלחת לשכבת ה-Business Process ומוכנסת למערכת.

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

סיכום
ניתן לראות שעל-ידי שימוש ב-MSMQ ניתן להגיע ל-Decoupling מקסימלי, ואף לאפשר פיתוח ממשקים בין מערכת המידע למערכת האינטגרציה הצמודה אליה בצורה מהירה . ע"י שימוש ב-Provider וב-Adapter, ניתן לבצע אינטגרציה עם מערכות שונות בעלות מימשקים שונים, עם תלות מינימלית בין המערכות ותמיכה בשיטות תקשורת שונות. סביבת הפיתוח של מיקרוסופט - .NET, והכלים בה כגון WCF, MSMQ וכדומה מאפשרים פיתוח אפליקציות ויצירת ממשקים באופן המאפשר לשמור על רמת הביצועים במערכות, שמירה על רמת אבטחת מידע וקיום של אי תלות בין המרכיבים השונים של הפתרון. קיימות סיבות נוספות לבחירה בארכיטקטורה הזו, בהן אני מקווה להתעמק במאמרים נוספים.