גרסאות שירותם בסביבת SOA ESB

ישנן מספר דרכים להוריד את מספר הגרסאות של שירותים בסביבת SOA\ESB ארגונית.

1. דרך ראשונה היא להשתמש ביכולות ה- XML של פלטפורמות הריצה או יכולות ה- adaptors . מדובר ביכולת XML והיא ל"התעלם" מפרמטרים שאינם דרושים. כלומר אם ישנה הרחבה של שדר XML לטובת אחת מהאפליקציות שמשתמשות בשירות, הרי ששאר האפליקציות יתעלמו מההרחבה. זאת הדרך הטובה ביותר להשארות בגרסה אחת משותפת לכל המשתמשים בשירות אולם דרך זו אינה מתאימה כאשר יש שינוי במפתח וכמו כן אינה מתאימה לסוגים שונים של פלטפורמות legacy (לדוגמה מבני נתונים מורכבים בקובול).
2. דרך אחרת היא לתמוך במספר גרסאות אבל ברמת ה- Bus\Broker ללא שינוי ברמת האפליקציות שמשתמשות בשירותים. כאשר אפליקציה מבקשת להשתמש בשירות ה- broker יודע מי הוא מבקש השירות ולכן יכול לנתב לכל אפליקציה את הגרסה המתאימה לה. כלומר מדובר במספר גרסאות בסביבת ה- Bus\Broker אך ברמת האפליקציות כולן קוראות לאותו שירות. ניתן לממש זאת גם על ידי שירות אחד שמכיל את כל הפרמטרים הנדרשים על ידי כל האפליקציות כאשר ה- Broker\Bus מחליט איזה פרמטרים ישלחו לאיזה דורש שירות. כלומר מדובר על ניהול גרסאות אבל במעטפת שירותית יחידה.
3. הדרך הנוספת היא כן להשתמש בגרסאות שונות גם ברמת האפליקציה הדורשת כאשר מציינים איזה גרסת שירות נדרשת (ניתן לממש זאת ברמת מעטפת ב- SOAP , ב- URL או בדרכים אחרות).

תובנות נוספות שקשורות לגרסאות בסביבה SOA מורכבת:
1. אין מנוס מלהגדיר מספר גרסאות לשירותים. אחד הארגונים קבע כלל שעל פיו אין יותר מ- 2 גרסאות ועומד בהצלחה בכלל זה.
2. יש לתעד בצורה טובה איזה שירות נמצא בשימוש על ידי איזה אפליקציה. ניתן בשלב ראשוני לבצע זאת ידנית (excel) אך בשלבים מתקדמים יותר יש לעבור לכלי soa governance.
3. ככל שבונים מלכתחילה את עץ השירותים בצורה טובה יותר- הסתכלות ארגונית כוללנית המייצגת את הישויות הארגוניות בצורה כללית שמותאמת לכל המערכות, הצורך בשינויים ועקב כך גם בגרסאות שונות של שירותים – יורד.


נקודות אלו יכולות לסייע לארגונים לצמצם עד כמה שניתן את מספר הגרסאות הקיימות לכל שירות אולם בסופו של דבר כל ארגון צריך להתמודד על הסוגיה של ניהול גרסאות השירותים וכאן המקום לכלי soa governance.

מאמר שלי התפרסם - Bold CIO it is SOA Time

מאמר שלי התפרסם ב- CUTTER -

Bold CIO -- It Is SOA Time!

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

מצ"ב קישור למאמר -
http://www.cutter.com/content/itjournal/fulltext/advisor/2009/itj090325.html

.

25 March 2009
Bold CIO -- It Is SOA Time!
by Pini Cohen

A lot has been said lately about service-oriented architecture (SOA). Still, I would like to take a look at another angle of SOA adoption in the light of the current economic turmoil.

SOA adoption has many layers: the basic enterprise service bus (ESB) infrastructure, business process management (BPM) workflow tools, other SOA-related tools, such as BAM (business activity monitoring) or business rules engine (BRE), and SOA governance -- both runtime and design time.

However, despite the fact that organizations have these tools, SOA adoption remains low. The reason for the low adoption rates is that SOA requires a significant change in the process of application development and hence a real shift of power inside the IT organization.

Currently, application development for specific lines of business (LOBs) is done by a corresponding developing team inside the IT organization. For example, the logistics organization applications are developed by the "logistics development team," the marketing applications are developed by the "marketing development team," and so forth. If, for example, the logistics LOB manager wants new features in an existing application or a new application, he or she goes to the "logistics development team," asks the team to do what's needed, gets an internal "quote," and delivers the money internally. Then the "logistics development team" is responsible for delivering what was agreed upon and sometimes will need help from other development teams.

With SOA, this process is invalid. When the logistics LOB manager wants new features, he or she goes to the "business IT architect" or equivalent function, such as in business relationship management (BRM). The business IT architect will ask the "logistics development team" to develop some of the features but will direct the "marketing development team," for example, to develop other features and also will use some features and/or services that were already being developed, for example, by the HR team.

This is reuse. This is agility. This is standardization. This is SOA. But this is also what stops SOA, since the head of the "logistics development team" feels that this lowers his or her position within the organization. In many organizations, the LOB development managers were against this dramatic process change and were able to stop it.
The Bottom Line

In the current economic situation, however, both the lower-level workers and the managers are very keen to keep their jobs. They are therefore willing to accept change much more than they were willing to before. So this is the time for process/organizational change that will enable better IT and, from this perspective, will enable SOA. So, as I said in the title of this Advisor: bold CIO -- this is SOA time.

-- Pini Cohen

תכונות SOA Governance

להלן רשימה בסיסית של תכונות שנדרשות מפתרון SOA Governance:
באופן בסיסי, צריך לחלק את התכונות האלה ל- run time ול- design.

• פרטים על השירות – באיזה שרת מותקן , פרמטרים, methods, וכד'.
• דוגמאות לשימוש בשירות
  
• הקשרים בין השירותים
  
• מי משתמש באיזה שירות (כלומר קשור ל- run time וגם ל-design)
  
• מה ה- Quality of Service שאמורים לקבל משירות (השבתה, זמני תגובה וכד'). וגם צריך לנהל את הדרישות לכל שירות. כלומר אם שירות יכול לתת תשובה 10 פעמים בשנייה, אבל רוצים להשתמש בו יותר מ- 10 פעמים בשנייה- המערכת צריכה להתריע
  
• אופציונלי - הגדרה של עדיפויות . לקוח A עדיף על לקוח B.
  
• ניהול שינויים. כאשר משתנה משהו – על מי משפיע. מי צורך איזה גרסה.
  
• רשימה של כל השירותים + חיפוש + תאור כולל מקורות המידע של השירותים.
  
• ביצוע workflow דרך המוצר (הוספת שירות חדש, עדכון שירות, ביטול שירות וכד')
  גילוי אוטומטי של שירותים (גילוי WS).
  
• הגדרה של סטנדרטים ואכיפתם מבחינת שמות משתנים, שמות methods, אבטחת מידע וכד'.
  
• הגדרות של מדיניות – מי יכול להשתמש באיזה שירות ותחת איזה תנאי (דוגמה – שירות זמין ל- X רק בשעות היום). מה קורה עם משנים מדיניות באמצע ) ואז פתאום חלק מהדברים עומדים במדיניות וחלק לא)?
  י
• כול לבצע subscription – מקבלים הודעה על כל שינוי בתחום מסויים.
  
• תמיכה ב- UDDI
  
• דברים ניהוליים על הכלי – אבטחת מידע (מי יכול להשתמש בכלי, האם לכתוב או גם לעדכן וכד'), גיבוי – מסד נתונים, וכד'.
  
• אגב, אם הכלי קשור לדברים נוספים – כלומר מקבל מידע מסביבת .net לדוגמה, מה קורה אם הקשר ניתק (הורדת השרת) האם יודעים לסנכרן את השינויים?
  
• התייחסות לגיבוי של שירותים. כלומר שירות אחד שמומש על ידי שני שרתים פיזיים לצרכי גיבוי.
  LOG של היסטוריה.
  
• דוחות לגבי מצב ה- SOA בארגון – דברים כמו – מי הם השירותים שהכי משתמשים בהם? מי הם השירותים הכי יציבים וכד'. גם ברמת RUN וגם ברמת DESIGN
  
• אפשרות לטיפול במסמכים (קבצים) נילווים לשירותים
  
• אפשרות לשים בכלי דברים שהם customized. גם מבחינת מידע. גם מבחינת ה- flow שמתבצע (דוגמה – flow של אישור שירות חדש).
  
• אופציונלי – קשר לכלי פיתוח. לדוגמה, כאשר מוסיפים Module שהוא PUBLIC חדש לפרוייקט ב- .net אז ה- module מופיע גם כשירות בכלי. כנ"ל לגבי כלי UML.