soa-שאלה מקצועית

[שונמים]

soa-שאלה מקצועית

היי, soa מבחינתי מהווה פתרון מתודולוגי לשימוש בשירותים של מערכות מורשת (legacy) מעל מעטפת webית. האם תוכלו להסביר לי הקשר בין זה לבין העובדה המתוארת המייצגת את OO כמתודולוגיה שאמורה היתה לפתור את הבעיה הנתונה בעולם המערכות הבינונית (מבחינת גודל)? במילים פשוטות מה הקשר בין מתודולוגיית OO וCO לבין soa? תודה רבה מראש, עמי

 

[arnonrgo]

טוב אז ככה

לדעתי SOA מאד רחוקה מההגדרה שלך 1. SOA לא תלוי בטכנולוגיה מסוימת (webית או אחרת) 2. SOA זה קודם כל business orientation - חיתוך של היכולות של העסק לפי תחומים בעלי הדיקות גבוהה בגרנולריות גדולה 3. loose coupling 4. קישוריות מבוססת messages 5. style ארכיטקטוני (רצ"ב מצגת שלי על נושא SOA ) Component orientation ו Object Orientation הינם קיוונים ארכיטקטונים אחרים - בגרנולריות נמוכה ונמוכה מאד (בהתאמה) כאשר המטרות והעקרונות שונים בין 3 השיטות (גם אם חלק מהקווים דומים) בכל מקרה כאשר ממשים שרות - אפשר להשתמש ב OO או CO ארנון

 

[ייוניי]

לגבי גרנולריות

אני חושב שהפכת את הסדר. אם תשווה את כמות השירותים במערכת מבוססת SOA עם כמות הרכיבים במערכת מבוססת Components אולי באמת תגיע למספר דומה. אבל ספרת פעם כמה אובייקטים קיימים בכל רגע נתון במערכת מבוססת OO?

 

[arnonrgo]

גרנולריות

הכוונה שלי היתה בין coarse grained (גרנולריות נמוכה או גסה - Services) לביןfine grained (גבוהה עבור אוביקטים) והכוונה לא למספר הדברים (אוביקטים/שרותים) אלא ליכולות שנחשפות ארנון

 

[arnonrgo]

גרנולריות

הכוונה שלי היתה בין coarse grained (גרנולריות נמוכה או גסה - Services) לביןfine grained (גבוהה עבור אוביקטים) והכוונה לא למספר הדברים (אוביקטים/שרותים) אלא ליכולות שנחשפות ארנון

 

[ייוניי]

SOA וכל השאר

קודם כל אני חושב שאתה צריך להפריד בין המושג "פתרון מתודולוגי" ו"פתרון טכנולוגי" (או "טכני"). הבעיה של שימוש בשירותים של מערכות legacy היא בעיה טכנית - צריך ליצור ערוץ תקשורת נוח מול המערכות הללו כדי שתהיה אפשרות להמשיך לעבוד איתן ולעבוד עם מערכות אחרות במקביל. ליצור מעטפות WEB סביב המערכות הללו זה פתרון מוזר ששמעתי אותו לא פעם אבל עדיין לא הבנתי למה הוא כדאי... בכל אופן יש פתרונות רבים נוספים ופרוטוקולים שונים שדרכם ניתן לתקשר עם מערכות legacy וזה הצד הטכנולוגי של העניין. אני לא מכניס בכלל לשיקול הזה שיקולים של מתודולוגיה כי הם לא רלוונטיים. מה הקשר בין המתודולוגיות שהזכרת במילים פשוטות? לדעתי, קשה מאוד להגדיר את המושגים הכל כך כוללניים הללו בצורה ברורה. בעיני SOA זה בכלל מודל עסקי של סיפוק שירותים לקהל לקוחות בעזרת פרוטוקולים וסטנדרטים עולמיים מקובלים - שקיבל תפנית לא ברורה למתודולוגיית פיתוח. לעומת CO ו-OO שמדברים יותר על רכיבי תוכנה ועל תקשורת ביניהם.

 

[user32]

תרשה לי לפרט על התפנית

אני מסכים עם ההגדרה שלך. SOA הוא יותר מודל עסקי ודרך להצגת מוצר ללקוח מאשר מתודולוגית פיתוח. אבל... כשיש מערכות מאוד גדולות שעובדים עליהם עשרות אלפי מתכנתים, המפתחים בעצמם הופכים להיות לקוחות (של מתכנתים אחרים). כשאני כתבתי קוד בSAP, היה לי ברור שהולכים להשתמש בו מתכנתים מגרמניה, הודו וארה"ב שמעולם לא פגשו (וכנראה גם לא יפגשו) אותי. המתכנתים האלה לא מקבלים את הקוד שלי בצורת source code אלא כשירות SOA שהם משלבים באפליקציות שלהם. לדעתי זה הרעיון בגדול.

 

[ייוניי]

שוב מדובר בבעיה טכנית

שכאמור ניתן לפתור בדרכים רבות ומגוונות. כמובן שכאשר אתה מעביר רכיב תוכנה לשימוש על ידי מתכנת אחר אתה צריך לחשוף API מתאים ונוח שהוא יוכל לעבוד איתו. SOAP הוא בהחלט אופציה אבל ממש לא האופציה היחידה ובמקרים רבים גם לא האופציה המועדפת. בכל מקרה עדיין לא ברור לי הקשר למתודולוגיה. כשאני אומר מתודולוגיה אני מתכוון לעקרונות מנחים בפיתוח תוכנה שמטרתם לשפר את יעילות כתיבת התוכנה. בדיוק כמו שהקמת שירותים שניתנים להפעלה אוטומטית במקביל/במקום שירותים הדורשים הפעלה ידנית הוא עקרון מנחה לחברות שעוסקות במתן שירותים שמטרתו לשפר את יעילות העסק.

 

[arnonrgo]

SOA

אני מסכים אתך שSOA היא לא מתודולוגית פיתוח אני לא מסכים שזהו מודל עיסקי לדעתי SOA זה Architecture Style שמתבסס על מספר עקרונות (שימוש בmessages , loose coupling, תלות בסכמה בלבד, אוטנומיות של שרות וכו) ארנון

 

[ייוניי]

נשמע מוכר...

loose coupling messages interfaces encapsulation כולן תכונות מוכרות מעולם ה OO. הדבר העיקרי שחסר ב Architecture Style הזה (כדי שהוא יהפוך ל OO לחלוטין) הוא polymorphism ולדעתי זהו חסרון משמעותי. נכון שקריאה לשירות היא בד"כ דינמית ומספר שירותים יכולים לחשוף ממשק זהה ולאפשר polymorphism אבל משום מה אני לא רואה שימושים רבים ביכולת הזו (לעומת הרבה מאוד שימושים ב OOP קלאסי). רכיב תוכנה לעולם לא יהיה אוטונומי לחלוטין כל עוד הוא מתקשר עם רכיבים אחרים בעזרת העברת מידע. גם אם המידע מבוסס על סכמה עדיין יש לקוח ושרת שצריכים להסכים על מהות המידע שמועבר מה שגורם לצמידות גבוהה ביניהם. אם הייתי צריך להשתמש בתשתית של Web Service לצורך תקשורת בין מערכות מרוחקות הייתי פועל באופן הבא: - אם אני עוסק בתכנות צד השרת בלבד - הייתי מנהל את התקשרות מול הלקוח מתוך מחלקה אחת בלבד שבה מוגדרת הסכמה ואשר אינה חושפת אותה בשום צורה לשאר המערכת. - אם אני עוסק בתכנות צד הלקוח בלבד - הייתי פועל באופן דומה. - אם אני כותב גם את הלקוח וגם את השרת - הייתי דואג לכך שהיישום של הלקוח והשרת יהיו תחת אותה מחלקה כך ששוב הסכמה לעולם לא תהיה חשופה לשאר המערכת! השאיפה היא כמובן להקטין צמידות ולצמצם כמה שיותר את ההשפעה של השימוש בשירות על תהליכים אחרים המתרחשים במערכת. צפיתי במצגת שבבלוג שלך והדברים הללו היו חסרים לי.

 

[arnonrgo]

SOA וOO

חשבתי ברמה מסוימת אתה יכול להגיד שSOA מזכיר OOנאמר שרות דומה לאוביקט אבל יש הרבה הבדלים בהרבה מאד רמות למשל יש הבדל בין הודעה של SOA לקריאה למתודה של OO - OO מעודד אינטראקציה עשירה בעוד SOA מדבר על תפיסת Document (הווה אומר מבחינת תפיסה בסיסית OO בנוי לסביבה לוקאלית וSOA לסביבה מבוזרת) דוגמא נוספת loose coupling דורש בחירה ממודעת ותכנון זהיר בOO – בSOA זה חלק מרעיונות הבסיסיים מה שהכי חשוב זהו הרמה בה משתמשים בפרדיגמה – OO ברמה ארכיטקטונית הוא די מוגבל (ללא styles נוספים כמו layers או styles לטובת distribution) 0 ובד"כ משתמשים בו ברמות של design ותכנות SOA הוא style ארכיטקטוני (כאשר המימוש יכול להיות בOO) ארנון בנוגע ל"גם אם המידע מבוסס על סכמה עדיין יש לקוח ושרת שצריכים להסכים על מהות המידע שמועבר מה שגורם לצמידות גבוהה ביניהם" בתפיסת של שרותים אני משתדל לתכנן סכמאות יותר מנקודת מבט של השרות והיכולות שהו מספק ולא מאינטראקציה בין לקוח ספציפי לשרות (לא מדובר כאן בשרת/לקוח) לגבי המצגת שלי - היא אמורה להיות אחת בסדרה (לא בטוח שאני אוכל לפרסם את כולה) - ובכל מקרה לא ניתן לכסות הכל במצגת אחת ארנון