דוגמאות לשירותים
- פותח הנושא ייוניי
- פורסם בתאריך
דוגמה קטנה מאצלי
(אם אני אראה שאנשים לא כותבים, אני אוסיף עוד כמה). קצת על המערכת (לשמחתי אני כבר לא בצבא, אז אני יכול לדבר על מערכות) - מערכת שממחשבת את עבודת המחלקה הפלילית בעירייה. המערכת עובדת מול מספר מערכות מידע אחרות, ביניהן מערכות של מחלקות הפיקוח של העירייה, מחלקות הרישוי של העירייה ומערכות של ביהמ"ש. המערכת מתוכננת כך שגם ה-UI של המערכת הוא צרכן שירותים (לכן הוא עובד רק מול שירותים ולא ישירות מול ה-DB חס וחלילה וגם לא מול רכיבי BL). אין לנו מידע שנחשף החוצה או מתעדכן שלא דרך שירות, וזאת מאחר ואפיון ראשוני של המערכת העלה שייתכנו בעתיד מספר ממשקים שגם מעדכנים את המערכת וגם מאחזרים מידע מהמערכת. ניקח לדוגמה שירות - איתור דיונים. מטרת השירות - להחזיר רשימת דיונים שמתקיימים לגבי תיק צרכן השירות - המערכת שלי ומערכות אחרות של הפיקוח שכתובות ב-vb6 הסכמה - אני לא אפרט, אבל בגדול, השירות מקבל מזהה של תיק ומחזיר dataset לפי סכמת XSD קבועה מראש (מה שמכונה typed dataset). בנוסף, מתוכנן שינוי בשירותים שלנו, כך שכל שירות יחזיר בנוסף לערך ההחזר המתוכנן גם קוד תוצאה (הצליח/נכשל מסיבה X/נכשל מסיבה לא ידועה), וזאת על-מנת שלא להעיף exceptions מהשירות.
(אם אני אראה שאנשים לא כותבים, אני אוסיף עוד כמה). קצת על המערכת (לשמחתי אני כבר לא בצבא, אז אני יכול לדבר על מערכות) - מערכת שממחשבת את עבודת המחלקה הפלילית בעירייה. המערכת עובדת מול מספר מערכות מידע אחרות, ביניהן מערכות של מחלקות הפיקוח של העירייה, מחלקות הרישוי של העירייה ומערכות של ביהמ"ש. המערכת מתוכננת כך שגם ה-UI של המערכת הוא צרכן שירותים (לכן הוא עובד רק מול שירותים ולא ישירות מול ה-DB חס וחלילה וגם לא מול רכיבי BL). אין לנו מידע שנחשף החוצה או מתעדכן שלא דרך שירות, וזאת מאחר ואפיון ראשוני של המערכת העלה שייתכנו בעתיד מספר ממשקים שגם מעדכנים את המערכת וגם מאחזרים מידע מהמערכת. ניקח לדוגמה שירות - איתור דיונים. מטרת השירות - להחזיר רשימת דיונים שמתקיימים לגבי תיק צרכן השירות - המערכת שלי ומערכות אחרות של הפיקוח שכתובות ב-vb6 הסכמה - אני לא אפרט, אבל בגדול, השירות מקבל מזהה של תיק ומחזיר dataset לפי סכמת XSD קבועה מראש (מה שמכונה typed dataset). בנוסף, מתוכנן שינוי בשירותים שלנו, כך שכל שירות יחזיר בנוסף לערך ההחזר המתוכנן גם קוד תוצאה (הצליח/נכשל מסיבה X/נכשל מסיבה לא ידועה), וזאת על-מנת שלא להעיף exceptions מהשירות.
-->
1. אכן מערכת WEB 2. השירותים מבצעים את עבודתם די מהר, אבל יש לי בעיה אחרת מאחר והשירותים שלי מחולקים לפי ישויות המידע. במקרה של המערכת שלי, לפעמים אני נדרש להציג לגבי ישות מידע ראשית (תיק בימ"ש) הרבה מאוד פרטים מישויות ה"בנים" שלו, מה שגורם לי הרבה טיולים ל-Services (להביא רשימת נאשמים, להביא רשימת דיונים, להביא רשימת החלטות וכו'). מאחר וסביבת הפיתוח שלי איטית יותר מסביבת הריצה (ה-DB חלש יותר), אני אדע יותר טוב איפה צריך לשפר ביצועים, כאשר אעבור לשלב הטסטינג. כרגע הפתרון הוא לספוג את הביצועים ולהשקיע במנגנוני cache בצד ה-Client 3. מערכת ה-WEB שונה במראה ממערכת ה-VB, ולכן שילוב מסכי WEB מתוך ה-VB זה יראה גועל נפש. בנוסף, מערכות ה-VB הן בשימוש משתמשים אחרים, מתחום שונה, אשר יש להם עניין בלראות את הנתונים בפורמט שמתאים להם ובתצוגה שנוחה להם (קח לדוגמה את החשבון בנק שלך - כשאתה מסתכל על חשבון בנק בתור צרכן קצה של שירותי הבנק, אתה רואה מידע שונה ממה שפקיד הבנק רואה כשהוא מסתכל על החשבון שלך).
1. אכן מערכת WEB 2. השירותים מבצעים את עבודתם די מהר, אבל יש לי בעיה אחרת מאחר והשירותים שלי מחולקים לפי ישויות המידע. במקרה של המערכת שלי, לפעמים אני נדרש להציג לגבי ישות מידע ראשית (תיק בימ"ש) הרבה מאוד פרטים מישויות ה"בנים" שלו, מה שגורם לי הרבה טיולים ל-Services (להביא רשימת נאשמים, להביא רשימת דיונים, להביא רשימת החלטות וכו'). מאחר וסביבת הפיתוח שלי איטית יותר מסביבת הריצה (ה-DB חלש יותר), אני אדע יותר טוב איפה צריך לשפר ביצועים, כאשר אעבור לשלב הטסטינג. כרגע הפתרון הוא לספוג את הביצועים ולהשקיע במנגנוני cache בצד ה-Client 3. מערכת ה-WEB שונה במראה ממערכת ה-VB, ולכן שילוב מסכי WEB מתוך ה-VB זה יראה גועל נפש. בנוסף, מערכות ה-VB הן בשימוש משתמשים אחרים, מתחום שונה, אשר יש להם עניין בלראות את הנתונים בפורמט שמתאים להם ובתצוגה שנוחה להם (קח לדוגמה את החשבון בנק שלך - כשאתה מסתכל על חשבון בנק בתור צרכן קצה של שירותי הבנק, אתה רואה מידע שונה ממה שפקיד הבנק רואה כשהוא מסתכל על החשבון שלך).
-->
לגבי 2 - אני בדיוק חושב על הסיטואציה של מערכת WEB שבה כל קריאת HTTP מהלקוח גורמת לפתיחת SESSION-ים של HTTP לשרותי WEB (שאני מניח שמלווים בתהליכי הזדהות וכו'...) שבתורם מבצעים גישה ל DBMS וכו'... ה overhead נשמע עצום. שמעתי לאחרונה על חברה שהציע ללקוח מנגנון כזה מטעמי אבטחה ונזרקה מכל המדרגות בגלל עניין הביצועים. Caching בלקוח זה הרי לא ממש רלוונטי לאלמטים של הזנת נתונים וכמו שהזכרת במקרה של ריבוי שירותים זה יכול להיות מאוד משמעותי. ב Personal Google Homepage שלי יש כמה RSS Feeds שמאיטים משמעותית את העליה של הדף... לגבי 3 - אני חושב שאפשר לגרום למערכת WEB להראות מאוד דומה למערכת VB בעזרת Style Sheet פשוט וגם לשלב בין המערכות בצורה יפה. השאלה היא מהי המשמעות של שני הממשקים השונים, איך אתה מתמודד עם הכפילות? איזה מידע שונה רואה פקיד הבנק לגבי החשבון שלי שאני לא רואה? והשאלה היותר חשובה היא למה שהבנק יסתיר ממני את המידע הזה? בכל אופן הנקודה היא שגם אם המראה הוא שונה יש בו הרבה אלמנטים דומים שקצת חבל לכתוב פעמיים, לא? בייחוד כדי לפשט את התהליך ההגיוני שבו תצוגת המידע כוללת גם פעולות אפשריות לביצוע, כמו שאת הפעולות שהפקיד יכול לעשות בבנק אני יכול לעשות במחשבים שבסניף או באינטרנט...
לגבי 2 - אני בדיוק חושב על הסיטואציה של מערכת WEB שבה כל קריאת HTTP מהלקוח גורמת לפתיחת SESSION-ים של HTTP לשרותי WEB (שאני מניח שמלווים בתהליכי הזדהות וכו'...) שבתורם מבצעים גישה ל DBMS וכו'... ה overhead נשמע עצום. שמעתי לאחרונה על חברה שהציע ללקוח מנגנון כזה מטעמי אבטחה ונזרקה מכל המדרגות בגלל עניין הביצועים. Caching בלקוח זה הרי לא ממש רלוונטי לאלמטים של הזנת נתונים וכמו שהזכרת במקרה של ריבוי שירותים זה יכול להיות מאוד משמעותי. ב Personal Google Homepage שלי יש כמה RSS Feeds שמאיטים משמעותית את העליה של הדף... לגבי 3 - אני חושב שאפשר לגרום למערכת WEB להראות מאוד דומה למערכת VB בעזרת Style Sheet פשוט וגם לשלב בין המערכות בצורה יפה. השאלה היא מהי המשמעות של שני הממשקים השונים, איך אתה מתמודד עם הכפילות? איזה מידע שונה רואה פקיד הבנק לגבי החשבון שלי שאני לא רואה? והשאלה היותר חשובה היא למה שהבנק יסתיר ממני את המידע הזה? בכל אופן הנקודה היא שגם אם המראה הוא שונה יש בו הרבה אלמנטים דומים שקצת חבל לכתוב פעמיים, לא? בייחוד כדי לפשט את התהליך ההגיוני שבו תצוגת המידע כוללת גם פעולות אפשריות לביצוע, כמו שאת הפעולות שהפקיד יכול לעשות בבנק אני יכול לעשות במחשבים שבסניף או באינטרנט...
-->
לגבי session - מהגרסה הנוכחית שרצה אצלנו בפרודקשן, כמעט ולא מבחינים בזמן של הפנייה לשירות. מה שיותר מרגישים היום זה הזוועה של ה-postback של דוט נט. מסכים שאנחנו בונים היום באמצעות callback כאשר ב-callback מבוצעת פנייה לשירות, כמעט ולא מרגישים את הזמן של הפנייה לשירות (עוברת לפעמים פחות משניה משליחת הבקשה עד קבלת התוצאה). לגבי גישה ל-DBMS - בשביל זה יש מנגנונים כגון connection pooling שעוזרים להקטין את הזמן שנדרש לפתוח connection מול ה-DB (אם לא היו דברים כאלו, זה היה סיוט כמובן). לגבי caching - אכן caching זה בעייתי בהיבט של שמירה על עדכניות. בגלל שהמערכת שלי היא היחידה שמזינה נתונים אני מרשה לעצמי לשמור ב-cache את הנתונים הכי עדכניים, בידיעה שאני היחיד שמסוגל לעשות זאת (מערכת ה-VB לא יכולה לעשות זאת כי הנתונים יתעדכנו לה כל כמה שניות, אבל מצד שני, הנתונים שלי הם לא ה-main issue של המערכת והיא צריכה אותם רק מדי כמה זמן, לפי דרישה, כך שאני לא כל כך דואג לחצי שניה שיקח להם לאחזר את זה). לגבי המראה של המערכת - כל הרעיון של שירות הוא שאני מספק את המידע, לא את המראה, וזאת מאחר ואני לא רוצה לקחת על עצמי אחריות של עיצוב ממשק משתמש למערכת שאני לא מכיר וללקוח שאני לא מכיר. מי שצורך את המידע הוא זה שמכיר את הלקוח ואופן העבודה שלו והוא זה שצריך להתאים את הממשק לאופן העבודה. אם אותו לקוח יבוא ויאמר לי שהממשק שאני למשתמשים שלי טוב גם עבורו - אין לי בעיה שישתמש בו, אבל אני ספק שירותים, לא מעצב גרפי ! ראית פעם בפרטי חשבון הבנק שלך את פרטיך האישיים ? איפה אתה גר ? כמה חריגות אשראי היו לך מאז שפתחת את החשבון ? מה מנהל הבנק כתב על הבקשה שלך למשכנתא ? פקיד הבנק רואה פרטים שמעניינים אותו, אתה רואה פרטים שמעניינים אותך, אבל שניכם מקבלים את הנתונים מאותו מקור - זה כל העניין של צריכת שירותים זהים והצגתם בצורה שמתאימה ללקוח שצורך את המידע.
לגבי session - מהגרסה הנוכחית שרצה אצלנו בפרודקשן, כמעט ולא מבחינים בזמן של הפנייה לשירות. מה שיותר מרגישים היום זה הזוועה של ה-postback של דוט נט. מסכים שאנחנו בונים היום באמצעות callback כאשר ב-callback מבוצעת פנייה לשירות, כמעט ולא מרגישים את הזמן של הפנייה לשירות (עוברת לפעמים פחות משניה משליחת הבקשה עד קבלת התוצאה). לגבי גישה ל-DBMS - בשביל זה יש מנגנונים כגון connection pooling שעוזרים להקטין את הזמן שנדרש לפתוח connection מול ה-DB (אם לא היו דברים כאלו, זה היה סיוט כמובן). לגבי caching - אכן caching זה בעייתי בהיבט של שמירה על עדכניות. בגלל שהמערכת שלי היא היחידה שמזינה נתונים אני מרשה לעצמי לשמור ב-cache את הנתונים הכי עדכניים, בידיעה שאני היחיד שמסוגל לעשות זאת (מערכת ה-VB לא יכולה לעשות זאת כי הנתונים יתעדכנו לה כל כמה שניות, אבל מצד שני, הנתונים שלי הם לא ה-main issue של המערכת והיא צריכה אותם רק מדי כמה זמן, לפי דרישה, כך שאני לא כל כך דואג לחצי שניה שיקח להם לאחזר את זה). לגבי המראה של המערכת - כל הרעיון של שירות הוא שאני מספק את המידע, לא את המראה, וזאת מאחר ואני לא רוצה לקחת על עצמי אחריות של עיצוב ממשק משתמש למערכת שאני לא מכיר וללקוח שאני לא מכיר. מי שצורך את המידע הוא זה שמכיר את הלקוח ואופן העבודה שלו והוא זה שצריך להתאים את הממשק לאופן העבודה. אם אותו לקוח יבוא ויאמר לי שהממשק שאני למשתמשים שלי טוב גם עבורו - אין לי בעיה שישתמש בו, אבל אני ספק שירותים, לא מעצב גרפי ! ראית פעם בפרטי חשבון הבנק שלך את פרטיך האישיים ? איפה אתה גר ? כמה חריגות אשראי היו לך מאז שפתחת את החשבון ? מה מנהל הבנק כתב על הבקשה שלך למשכנתא ? פקיד הבנק רואה פרטים שמעניינים אותו, אתה רואה פרטים שמעניינים אותך, אבל שניכם מקבלים את הנתונים מאותו מקור - זה כל העניין של צריכת שירותים זהים והצגתם בצורה שמתאימה ללקוח שצורך את המידע.
נראה לי לא מספיק גמיש
ברגע שאתה מספק שירותים שהם מידע בלבד כאשר הפעולות והתצוגה של אותו מידע נקבעות אצל צרכן השירותים יש פה לדעתי כפילות של לוגיקה וקושי בהוספת לוגיקה נוספת למידע באופן מרוכז. כשאני חושב על שירות גמיש אני חושב על PayPal למשל. שירות שבו אתה מפנה את הלקוח לספק השירות והוא חוזר אליך אחרי שהתשלום בוצע וכך יש הפרדה יפה בין המכירה שביצעת לבין התשלום שהתבצע אצל PayPal. האתר שלהם דואג לכל תהליך התשלום כולל התצוגה והפעולות האפשריות וזה נותן להם חופש פעולה לעשות שינויים מרחיקי לכת בשירות בלי להשפיע על האתר שלך וההפך. כשאני חושב על שירות של עגלת קניות אני חושב על אותו דבר... לגבי הבנק לדעתי כל הפרטים של חשבון הבנק שלי מעניינים אותי. אפילו פרטים כמו הכתובת כדי שאני אוכל לוודא תמיד שאין בה טעות. זה שלא כולם מוצגים כרגע במערכות שיש בשוק זה עניין זמני. נראה לי שאם שירותים היו חושפים מידע מעוצב בלווי פעולות שניתן לבצע עליו זה היה חוסך הרבה כפילות במערכות שונות שכרגע צריכות "להבין" את משמעות המידע על מנת להציג אותו ולאפשר פעולות עליו. בכל אופן תודה על הדוגמא. חבל שאין יותר דוגמאות...
ברגע שאתה מספק שירותים שהם מידע בלבד כאשר הפעולות והתצוגה של אותו מידע נקבעות אצל צרכן השירותים יש פה לדעתי כפילות של לוגיקה וקושי בהוספת לוגיקה נוספת למידע באופן מרוכז. כשאני חושב על שירות גמיש אני חושב על PayPal למשל. שירות שבו אתה מפנה את הלקוח לספק השירות והוא חוזר אליך אחרי שהתשלום בוצע וכך יש הפרדה יפה בין המכירה שביצעת לבין התשלום שהתבצע אצל PayPal. האתר שלהם דואג לכל תהליך התשלום כולל התצוגה והפעולות האפשריות וזה נותן להם חופש פעולה לעשות שינויים מרחיקי לכת בשירות בלי להשפיע על האתר שלך וההפך. כשאני חושב על שירות של עגלת קניות אני חושב על אותו דבר... לגבי הבנק לדעתי כל הפרטים של חשבון הבנק שלי מעניינים אותי. אפילו פרטים כמו הכתובת כדי שאני אוכל לוודא תמיד שאין בה טעות. זה שלא כולם מוצגים כרגע במערכות שיש בשוק זה עניין זמני. נראה לי שאם שירותים היו חושפים מידע מעוצב בלווי פעולות שניתן לבצע עליו זה היה חוסך הרבה כפילות במערכות שונות שכרגע צריכות "להבין" את משמעות המידע על מנת להציג אותו ולאפשר פעולות עליו. בכל אופן תודה על הדוגמא. חבל שאין יותר דוגמאות...
כנראה שלא הבנת
השירותים שאני נתתי כדוגמה הם שירותים של אחזור מידע (הדוגמה הכי טיפשית - שירות מידע באינטרנט שנותן לך מידע לגבי מזג אוויר). מה שאתה תיארת לגבי PayPal זה שירות מבוסס messaging שבו אתה שולח פנייה לשירות ולאחר מכן, מתישהו, אתה מקבל תשובה בחזרה באמצעים כלשהם (delegate, mail וכו'). שירותים מבוססי messaging לא מתאימים לכל המקרים, אלא מתאימים לסט מסוים של מקרים בהם נדרש אישור על ביצוע פעולה, אך האישור לא נדרש מיידית. אני יכול לתאר לך לדוגמה מקרה אצלנו, שבו אנחנו נדרש בקרוב לפתוח תיק בבימ"ש באמצעות שירות messaging של משרד המשפטים. מאחר והשירות שלהם הוא מבוסס messaging גם השירות שלנו יהיה מבוסס messaging ולכן, כאשר המשתמש יפעיל שירות "פתח תיק בבימ"ש" הוא יקבל הודעה ש"בקשתך התקבלה" ולאחר כמה דקות/שעות יקבל אישור או חיווי על בעיות. שים לב שגם מה שתיארת מפריד בין המסך של ההזנה לבין השירות - ספק השירות (paypal ?) רק מקבל מידע על התשלום, איך הזנת את התשלום ? זה כבר בעיה של האתר שפונה לשירות. דבר דומה יש לך במערכות בארץ שעובדות עם חיוב של "שבא" - יש אלפי מערכות שונות שעובדות עם השירות הזה, כל אחת מהן נראית אחרת, אבל כולן בסוף שולחות אותו מידע לשירות ומקבלות אותו מידע בחזרה. לגבי נושא הבנק - אין קשר בין אי ההצגה לבין עניין זמני. זוהי החלטה של מי שבנה את מערכת הבנק, לפי איזשהן הגדרות של מישהו שאמור להבין עניין וידע לנתח את דרישות הצרכנים (אתה ואני) ולזהות מה אנחנו מעוניינים לדעת ומה לא. אני לא משער שבעתיד יתנו לך לדעת מידע לגבי מדוע סרבו לך למשכנתא, כי זה חלק מהמידע הפרטי שבנק שומר עליך (אני חושב) ושהוא אינו מעוניין לחשוף אותו בפניך - אבל ייתכן מאוד שהוא חושף אותו לבנקים אחרים או למוסדות אחרים כלשהם.
השירותים שאני נתתי כדוגמה הם שירותים של אחזור מידע (הדוגמה הכי טיפשית - שירות מידע באינטרנט שנותן לך מידע לגבי מזג אוויר). מה שאתה תיארת לגבי PayPal זה שירות מבוסס messaging שבו אתה שולח פנייה לשירות ולאחר מכן, מתישהו, אתה מקבל תשובה בחזרה באמצעים כלשהם (delegate, mail וכו'). שירותים מבוססי messaging לא מתאימים לכל המקרים, אלא מתאימים לסט מסוים של מקרים בהם נדרש אישור על ביצוע פעולה, אך האישור לא נדרש מיידית. אני יכול לתאר לך לדוגמה מקרה אצלנו, שבו אנחנו נדרש בקרוב לפתוח תיק בבימ"ש באמצעות שירות messaging של משרד המשפטים. מאחר והשירות שלהם הוא מבוסס messaging גם השירות שלנו יהיה מבוסס messaging ולכן, כאשר המשתמש יפעיל שירות "פתח תיק בבימ"ש" הוא יקבל הודעה ש"בקשתך התקבלה" ולאחר כמה דקות/שעות יקבל אישור או חיווי על בעיות. שים לב שגם מה שתיארת מפריד בין המסך של ההזנה לבין השירות - ספק השירות (paypal ?) רק מקבל מידע על התשלום, איך הזנת את התשלום ? זה כבר בעיה של האתר שפונה לשירות. דבר דומה יש לך במערכות בארץ שעובדות עם חיוב של "שבא" - יש אלפי מערכות שונות שעובדות עם השירות הזה, כל אחת מהן נראית אחרת, אבל כולן בסוף שולחות אותו מידע לשירות ומקבלות אותו מידע בחזרה. לגבי נושא הבנק - אין קשר בין אי ההצגה לבין עניין זמני. זוהי החלטה של מי שבנה את מערכת הבנק, לפי איזשהן הגדרות של מישהו שאמור להבין עניין וידע לנתח את דרישות הצרכנים (אתה ואני) ולזהות מה אנחנו מעוניינים לדעת ומה לא. אני לא משער שבעתיד יתנו לך לדעת מידע לגבי מדוע סרבו לך למשכנתא, כי זה חלק מהמידע הפרטי שבנק שומר עליך (אני חושב) ושהוא אינו מעוניין לחשוף אותו בפניך - אבל ייתכן מאוד שהוא חושף אותו לבנקים אחרים או למוסדות אחרים כלשהם.
-->
אני לא חושב שהעניין של שירות סינכרוני או אסינכרוני הוא הנקודה שמפריעה לי. לגבי PayPal אתה לא מדייק כי מה שאני מספק ל PayPal כשאני שולח אליהם את הלקוח זה כמה כסף הם צריכים לחייב אותו ואיך להחזיר אותו אלי בצורה מאובטחת כך שאדע שהוא אכן שילם (או לשלוח לי מייל). את כל הפרטים שהם צריכים כדי לחייב אותו הוא ממלא באתר שלהם וזה מה שעושה את הפתרון שלהם לפשוט ומתאים גם לאתרים HTML-ים לחלוטין. לזה אני קורא שירות אוטונומי! לגבי "שבא" זה בהחלט מתסכל שצריך לעשות בעצמך את כל קליטת הנתונים ובדיקות התקינות וכו'... ככה זה כשיש מונופול... (אני מקווה שהם באמת מונופול ואני לא עושה מעצמי צחוק
) אבל מה שקצת מתסכל כשעובדים עם שירות אחד או שניים באתר יכול להיות בעיה תחזוקתית גדולה כשעובדים עם אפליקציה שמשתמשת בעשרות או מאות "שירותים" כאלה. אם כל שירות מהווה תהליך העברת מידע בלבד זה אומר שיש הרבה עבודה שהלקוח צריך לעשות ואם יש הרבה לקוחות אז יש הרבה עבודה כפולה.
אני לא חושב שהעניין של שירות סינכרוני או אסינכרוני הוא הנקודה שמפריעה לי. לגבי PayPal אתה לא מדייק כי מה שאני מספק ל PayPal כשאני שולח אליהם את הלקוח זה כמה כסף הם צריכים לחייב אותו ואיך להחזיר אותו אלי בצורה מאובטחת כך שאדע שהוא אכן שילם (או לשלוח לי מייל). את כל הפרטים שהם צריכים כדי לחייב אותו הוא ממלא באתר שלהם וזה מה שעושה את הפתרון שלהם לפשוט ומתאים גם לאתרים HTML-ים לחלוטין. לזה אני קורא שירות אוטונומי! לגבי "שבא" זה בהחלט מתסכל שצריך לעשות בעצמך את כל קליטת הנתונים ובדיקות התקינות וכו'... ככה זה כשיש מונופול... (אני מקווה שהם באמת מונופול ואני לא עושה מעצמי צחוק
פול מקרטני
New member
אתה צריך להפריד בין שירות לאתר
שירות אינו בהכרח אתר אינטרנט. ברגע שאתה מפריד בין המידע לתצוגה,דווקא אז המערכת הרבה יותר גמישה, קח לדוגמא שירות דימיוני לחיפוש מספרי טלפון ושני לקוחות אחד שרואה ואחד שאינו(קרי משתמש בכתב ברייל) אני לא מניח שאתר מעוצב יעזור לזה שמשתמש בכתב ברייל.....זו כמובן דוגמא פשטנית אבל בעולם גלובלי ישנם מיני לקוחות(לאו דווקא אנשים) רבים לשירות התאמת השירות לכל סוג של לקוח תדרוש מספק השירות עבודה שאינה מוכן לה,וייתכן שגם אינו בקיא בטכנולוגיה הנדרשת. בברכה.
שירות אינו בהכרח אתר אינטרנט. ברגע שאתה מפריד בין המידע לתצוגה,דווקא אז המערכת הרבה יותר גמישה, קח לדוגמא שירות דימיוני לחיפוש מספרי טלפון ושני לקוחות אחד שרואה ואחד שאינו(קרי משתמש בכתב ברייל) אני לא מניח שאתר מעוצב יעזור לזה שמשתמש בכתב ברייל.....זו כמובן דוגמא פשטנית אבל בעולם גלובלי ישנם מיני לקוחות(לאו דווקא אנשים) רבים לשירות התאמת השירות לכל סוג של לקוח תדרוש מספק השירות עבודה שאינה מוכן לה,וייתכן שגם אינו בקיא בטכנולוגיה הנדרשת. בברכה.
פול מקרטני
New member
מסכים איתך.
תצוגות שונות
תראה, גם אדם שקורא ברייל יקרא את הטקסט "מספר הטלפון שנמצא הוא: XXXXXX" והוא בוודאי לא יקרא את המידע בלבד ללא עיצוב כלשהו... כשאני מדבר על תצוגה אני מדבר על הטרנפורמציה בין מידע באופן שבו המערכת הממוחשבת רואה אותו (ובו הוא כנראה נשמר ב DB) לבין מידע באופן שבו משתמש הקצה רואה אותו (במקרה של קוד מטבלת lookup זה הבדל גדול מאוד). ומה אם מספר הטלפון מוצג עם כפתור לידו שמקשר אותך לשירות "ספר הטלפונים הפרטי שלי" ורושם את המספר אוטומטית בספר שלך? האם כל אתר שמשתמש בשירות צריך להוסיף את הכפתור בעצמו? קצת חבל... כשאני מספק שירות ללקוח אני דורש בעיקר מעצמי ובהחלט מוטלת עלי ההתאמה של השירות לכל סוג של לקוח ולכל סוג של טכנולוגיה, אחרת איזה מין ספק שירותים אני? למיטב הבנתי של שימוש ב Web Services בעולם ה B2B הלקוח משלם לי כסף טוב על מנת שאספק לו את השירות עד הסוף ולא רק שירותי מידע שיקח לו חודש לעשות להם אינטגרציה לתוך המערכת שלו. אתה רוצה לומר לי שבתור לקוח תעדיף שירות שנותן לך אפשרות לבצע קריאות SOAP שמחפשות במאגר טלפונים ומחזירות תוצאות, על גבי שירות שמוסיף לך באתר אזור "חיפוש טלפון" ודפי "חיפוש טלפון מתקדם" ולא דורש ממך לכתוב שורת קוד על מנת שיעבוד?
תראה, גם אדם שקורא ברייל יקרא את הטקסט "מספר הטלפון שנמצא הוא: XXXXXX" והוא בוודאי לא יקרא את המידע בלבד ללא עיצוב כלשהו... כשאני מדבר על תצוגה אני מדבר על הטרנפורמציה בין מידע באופן שבו המערכת הממוחשבת רואה אותו (ובו הוא כנראה נשמר ב DB) לבין מידע באופן שבו משתמש הקצה רואה אותו (במקרה של קוד מטבלת lookup זה הבדל גדול מאוד). ומה אם מספר הטלפון מוצג עם כפתור לידו שמקשר אותך לשירות "ספר הטלפונים הפרטי שלי" ורושם את המספר אוטומטית בספר שלך? האם כל אתר שמשתמש בשירות צריך להוסיף את הכפתור בעצמו? קצת חבל... כשאני מספק שירות ללקוח אני דורש בעיקר מעצמי ובהחלט מוטלת עלי ההתאמה של השירות לכל סוג של לקוח ולכל סוג של טכנולוגיה, אחרת איזה מין ספק שירותים אני? למיטב הבנתי של שימוש ב Web Services בעולם ה B2B הלקוח משלם לי כסף טוב על מנת שאספק לו את השירות עד הסוף ולא רק שירותי מידע שיקח לו חודש לעשות להם אינטגרציה לתוך המערכת שלו. אתה רוצה לומר לי שבתור לקוח תעדיף שירות שנותן לך אפשרות לבצע קריאות SOAP שמחפשות במאגר טלפונים ומחזירות תוצאות, על גבי שירות שמוסיף לך באתר אזור "חיפוש טלפון" ודפי "חיפוש טלפון מתקדם" ולא דורש ממך לכתוב שורת קוד על מנת שיעבוד?
פול מקרטני
New member
תלוי בסוג הלקוח
אם אתה קורא למשתמש קצה בתור לקוח אז בוודאי שהדרישות שלו שונות מלקוח שהוא אינטגרטור שמשתמש במספר שירותים על מנת להפיק אפלקציה מסוימת אם נניח אני אינטגרטור שרוצה להקים מערכת הנותנת למשתמש קצה אפשרות להכניס נקודת ציון,לקבל כתובת,ולשלוח לכתובת מכתב ויש לי גישה לשני שירותים-שירות הממפה נ.צ לכתובת, ושירות שליחת מכתב אני אעדיף שהשירותים האלה יתנו לי מידע בצורה סנטדרטית שאוכל לעבד קרי XML למשל,ברגע שהמידע שמגיע אלי מכיל מידע על דרך תצוגת הנתונים זה מגביל אותי.מה יקרה אם יחזירו לי HTML 3 ואני רוצה לתמוך במכשירים שמציגים HTML 2?
אם אתה קורא למשתמש קצה בתור לקוח אז בוודאי שהדרישות שלו שונות מלקוח שהוא אינטגרטור שמשתמש במספר שירותים על מנת להפיק אפלקציה מסוימת אם נניח אני אינטגרטור שרוצה להקים מערכת הנותנת למשתמש קצה אפשרות להכניס נקודת ציון,לקבל כתובת,ולשלוח לכתובת מכתב ויש לי גישה לשני שירותים-שירות הממפה נ.צ לכתובת, ושירות שליחת מכתב אני אעדיף שהשירותים האלה יתנו לי מידע בצורה סנטדרטית שאוכל לעבד קרי XML למשל,ברגע שהמידע שמגיע אלי מכיל מידע על דרך תצוגת הנתונים זה מגביל אותי.מה יקרה אם יחזירו לי HTML 3 ואני רוצה לתמוך במכשירים שמציגים HTML 2?
לגבי HTML 2/3
כמו שהזכרתי על השירות מוטל התפקיד לשרת אותך נאמנה ולתת לך תשובה שמתאימה לצרכיך קרי HTML 2 או 3 בהתאם לדרישתך. איזה מידע יש לך לעבד כאן? שלח את המשתמש לשירות הנ.צ. (שבטח יציג לו מפה מגניבה וכו'...) קבל בחזרה כתובת ואז שלח אותו עם הכתובת לשירות הדואר (
) שיתן לו חלון כתיבת מכתב (או שליחת חבילה שבה מוצר שהוא יזמין משירות OLSALE) וישלח עבורו את המכתב. לך אין שום עניין ב"לעבד" את המידע הזה, וכמה שפחות תדע על מה שקורה ככה יהיה לך פחות קוד לתחזק...
כמו שהזכרתי על השירות מוטל התפקיד לשרת אותך נאמנה ולתת לך תשובה שמתאימה לצרכיך קרי HTML 2 או 3 בהתאם לדרישתך. איזה מידע יש לך לעבד כאן? שלח את המשתמש לשירות הנ.צ. (שבטח יציג לו מפה מגניבה וכו'...) קבל בחזרה כתובת ואז שלח אותו עם הכתובת לשירות הדואר (
פול מקרטני
New member
ידעתי שאסור לי להשתמש עם הדוגמא
הזאת....בגלל שכולם כבר מכירים את האתרים שמציגים מפות על פי נ.צ...וזה מבלבל העניין הוא שאין בינינו הסכמה מי בדיוק הוא הלקוח ולכן אנחנו לא מסכימים. צריך להבין שלכל לקוח יש דרישות שונות לפי ה"מרחק" שלו ממקור השירות. בברכה.
הזאת....בגלל שכולם כבר מכירים את האתרים שמציגים מפות על פי נ.צ...וזה מבלבל העניין הוא שאין בינינו הסכמה מי בדיוק הוא הלקוח ולכן אנחנו לא מסכימים. צריך להבין שלכל לקוח יש דרישות שונות לפי ה"מרחק" שלו ממקור השירות. בברכה.
שרותים
שרותי תוכנה (במובן של SOA) נועדו לצריכה ע"י תוכנות אחרות (שרותים אחרים או לקוחות המפרמטים את המידע לתצוגה) באופן עקרוני מחזירים מידע עפ"י חוזה שמפורסם ע"י השרות (חוזה מכיל רשימה של הודעות שניתן לשלוח לשרות והודעות שהשרות מפרסם) ועפ"י Policies שנקבעים (למשל דרישה לחתימה אלקטרונית, הצפנה, הבטחה לתשובה תוך X שניות וכו) צורת הדיבור עם השרות web-services,messaging או כל צורה אחרת (לדעתי) היא עוד חלק מהחוזה בנוסף שרותים לא נבנים ספציפית לכל לקוח - זה פוגם בloose coupling שהוא אחת הסיבות המרכזיות ללכת בכיוון הזה בכלל לדוגמא google יש להם אתר (תצוגה) ויש להם שרותים: Google Services לאמזון יש אתר ויש להם שרותים: Amazon Services ואלו דברים שונים לחלוטין ארנון
שרותי תוכנה (במובן של SOA) נועדו לצריכה ע"י תוכנות אחרות (שרותים אחרים או לקוחות המפרמטים את המידע לתצוגה) באופן עקרוני מחזירים מידע עפ"י חוזה שמפורסם ע"י השרות (חוזה מכיל רשימה של הודעות שניתן לשלוח לשרות והודעות שהשרות מפרסם) ועפ"י Policies שנקבעים (למשל דרישה לחתימה אלקטרונית, הצפנה, הבטחה לתשובה תוך X שניות וכו) צורת הדיבור עם השרות web-services,messaging או כל צורה אחרת (לדעתי) היא עוד חלק מהחוזה בנוסף שרותים לא נבנים ספציפית לכל לקוח - זה פוגם בloose coupling שהוא אחת הסיבות המרכזיות ללכת בכיוון הזה בכלל לדוגמא google יש להם אתר (תצוגה) ויש להם שרותים: Google Services לאמזון יש אתר ויש להם שרותים: Amazon Services ואלו דברים שונים לחלוטין ארנון
פול מקרטני
New member
../images/Emo45.gif
הסתכלתי קצת על Amazon Services
שים לב קודם כל לעניין הטכנולוגיה. WSDL היא אולי technology independent אבל בסופו של דבר הם מספקים לך שם דוגמאות קוד לכל השפות כמעט וזה מוכיח שגם אם תספק WSDL + POLICY + Documentation עדיין קשה לתפעל שירותים בלי דוגמאות קוד. לדעתי אם Amazon היו מספקים לי פקד ASP.NET מקומפל שאני מוסיף לאתר שלי והוא עובד מולם באופן עצמאי זה היה הרבה יותר loosly coupled מאשר לדרוש ממני לכתוב פקד ספציפי כזה (או להעתיק מהדוגמא שלהם). ברגע שאני צריך לכתוב קוד ספציפי בשביל העבודה מול Amazon (מעבר לאותה שורת קוד שכתוב בה "האתר שלי עושה שימוש בשירות של Amazon") אני יוצר coupling. ואני מניח שאתה לא מתכוון ש Amazon יכולים להיות coupled אלי... הם הרי בכלל לא מודעים לקיומי. עכשיו, נניח שרמת ה loose coupling שאני מצפה לה היא באמת בלתי אפשרית בקנה מידה של Amazon שצריכים לתמוך בהרבה סוגים של לקוחות בלתי צפויים לחלוטין. זה לא אומר שצריך לאמץ את החסרון הזה (שהוא trade-off עיצובי) לתכנון שירותים שהם לפעמים פנים-אפליקטיביים וספציפיים ויכולים להיות מעוצבים בצורה שהיא הרבה יותר loosly coupled. הרי תדירות שינויי הדרישות בשירותים של Amazon היא נמוכה בסדרי גודל מתדירות שינויי הדרישות הממוצעת של מזמיני אפליקציות...
שים לב קודם כל לעניין הטכנולוגיה. WSDL היא אולי technology independent אבל בסופו של דבר הם מספקים לך שם דוגמאות קוד לכל השפות כמעט וזה מוכיח שגם אם תספק WSDL + POLICY + Documentation עדיין קשה לתפעל שירותים בלי דוגמאות קוד. לדעתי אם Amazon היו מספקים לי פקד ASP.NET מקומפל שאני מוסיף לאתר שלי והוא עובד מולם באופן עצמאי זה היה הרבה יותר loosly coupled מאשר לדרוש ממני לכתוב פקד ספציפי כזה (או להעתיק מהדוגמא שלהם). ברגע שאני צריך לכתוב קוד ספציפי בשביל העבודה מול Amazon (מעבר לאותה שורת קוד שכתוב בה "האתר שלי עושה שימוש בשירות של Amazon") אני יוצר coupling. ואני מניח שאתה לא מתכוון ש Amazon יכולים להיות coupled אלי... הם הרי בכלל לא מודעים לקיומי. עכשיו, נניח שרמת ה loose coupling שאני מצפה לה היא באמת בלתי אפשרית בקנה מידה של Amazon שצריכים לתמוך בהרבה סוגים של לקוחות בלתי צפויים לחלוטין. זה לא אומר שצריך לאמץ את החסרון הזה (שהוא trade-off עיצובי) לתכנון שירותים שהם לפעמים פנים-אפליקטיביים וספציפיים ויכולים להיות מעוצבים בצורה שהיא הרבה יותר loosly coupled. הרי תדירות שינויי הדרישות בשירותים של Amazon היא נמוכה בסדרי גודל מתדירות שינויי הדרישות הממוצעת של מזמיני אפליקציות...
פול מקרטני
New member
לא ממש הבנתי
איך פקד ASP.NET מקומפל שמשמש כ PROXY WEBSERVICE שונה באופן עקרוני משיטה אחרת להעברת הודעות לשירות? מנקודת ראייה מופשטת,מבחינתך כלקוח של השירות זה היינו הך?! "ברגע שאני צריך לכתוב קוד ספציפי בשביל העבודה מול Amazon (מעבר לאותה שורת קוד שכתוב בה "האתר שלי עושה שימוש בשירות של Amazon") אני יוצר coupling." אין רע ב COUPLING!!!! המטרה היא להגיע ל loose coupling ולא ל NONE COUPLING שזאת הרמה המקסימלית שבה אין בכלל תקשורת בין שירותים....( ראה דיאגרמה מצורפת)
איך פקד ASP.NET מקומפל שמשמש כ PROXY WEBSERVICE שונה באופן עקרוני משיטה אחרת להעברת הודעות לשירות? מנקודת ראייה מופשטת,מבחינתך כלקוח של השירות זה היינו הך?! "ברגע שאני צריך לכתוב קוד ספציפי בשביל העבודה מול Amazon (מעבר לאותה שורת קוד שכתוב בה "האתר שלי עושה שימוש בשירות של Amazon") אני יוצר coupling." אין רע ב COUPLING!!!! המטרה היא להגיע ל loose coupling ולא ל NONE COUPLING שזאת הרמה המקסימלית שבה אין בכלל תקשורת בין שירותים....( ראה דיאגרמה מצורפת)
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.