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