ישנן מספר דרכים להוריד את מספר הגרסאות של שירותים בסביבת 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.
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.
אין תגובות:
הוסף רשומת תגובה