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

מצב זה מציב לדעתי מספר בעיות חמורות:

  • בעיות הנוגעות לאבטחת המידע
  • בעיות הנוגעות לשרידות המידע
  • בעיות הנוגעות לקישור בין מערכות שונות
  • בעיות הנוגעות לשמישות המידע במקרה אסון אצל ספק התוכנה

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

למרות זאת, מנהלי רשת רבים יודעים בד"כ כיצד לאבטח באופן נורמלי אתר אינטרנט/אינטראנט, הגדרה שלו כ-HTTPS ובמדת הצורך הגדרת Client Certificates מורשים. היות וה-WebService הוא למעשה סוג של אתר אינטרנט ניתן לאבטח אותו באופן דומה.

נושא נוסף שהולך ומתחמם בשנים האחרונות הוא נושא האבטחה האפליקטיבית, יותר ויותר חברות אבטחת מידע כדוגמת צ'ק-פוינט ו-Fortinet שמות דגש חשוב על נושא האבטחה האפליקטיבית, דהיינו השקעה במנגנונים לניתוח התוכן המועבר זאת, בנוסף לגישה הקלאסית לניתוח התעבורה על בסיס ה-Port בו היא עוברת. היות ו-WebServices משתמשים בפרוטוקול SOAP לצורך הפניה למתודות השונות ניתן יחסית בקלות להגדיר חתימות XML של מתודות מאופשרות ב-Application Firewall הנמצא בתווך ובכך בעצם לספק שכבת הגנה אפליקטיבית נוספת.

בעיות הנוגעות לשרידות המידע
מערכות מידע רבות משתמשות במסדי נתונים דוגמת SQL ואוראקל על מנת לארגן את הנתונים. לצורך שיפור שרידות המידע חברות רבות משתמשות במנגנוני גיבוי או בשרתי איחסון מרכזיים דוגמת NetApp ו EMC. מנגנונים אלו דואגים להעביר את ה-DB למצב Maintenance על מנת לשמור על Consistency של מסד הנתונים.
עם זאת, ישנם מקרים בהם תיתכן בעיה בגישה הזו למשל באחד מהמקרים הבאים:
1. מסד הנתונים הוא מסד נתונים של Microsoft Access:
מסד נתונים של Microsoft Access הוא למעשה קובץ, כך שכאשר מנסים לגבות אותו אין כלל דרך להעביר אותו למצב Maintenance משום שאין לו שרת ולכן ייתכן מצב בו הנתונים שגובו ב-Snapshot או בקלטת הם למעשה בלתי תקינים ולא יהיה ניתן לשחזרם.
2. מערכת המידע לא נכתבה באופן תקין מבחינת פניה ל-DB
היות ובמקרים רבים הלקוח לא מודע לאופן בו נבנתה מערכת המידע שלו ייתכן בהחלט מצב שנתונים שהמערכת צריכה שיהיו בבת אחת במספר טבלאות למעשה נרשמים במספר טרנזקציות ולא כטרנזקציה אחת, במצב כזה, הנתונים ב-Snapshot ו/או על קלטת הגיבוי יהיו כביכול תקינים וניתנים לשיחזור אך מערכת המידע לא תצליח לעבוד משום שבזמן הגיבוי בוצעו רק חלק מהטרנזקציות הנחוצות.

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

בעיות הנוגעות לקישור בין מערכות שונות
באירגונים שלא משתמשים במערכות ERP גדולות אלא מעדיפים להשתמש ב-Best Of Breed מגיע במוקדם או במאוחר הצורך לקשר בין מערכות מידע שונות שנכתבו ע"י יצרנים שונים. בחלק מן המקרים אף מדובר ביצרנים שכבר לא קיימים ואי אפשר לבקש מהם לבצע את הפעולה.
בדרך כלל, לדרג הניהולי נושאים אלו נראים טריוויאליים מאד: "ברור שיש לקשר בין מערכת משאבי אנוש למערכת שכר".
כמובן שהנושאים האלו רחוקים מאד מלהיות פשוטים לביצוע, היות ומערכות שונות מאחסנות נתונים באופנים שונים התלויים פעמים רבות בנוחות של בית התוכנה.
הרעיון של שימוש ב-WebService כפלטפורמה הכרחית עבור כל מערכת שרוצים לקבל מבתי תוכנה שונים יכול להשתלם מאד בראייה עתידית בדיוק משום שגם אם היום קשה לנו לראות אילו מערכות אם בכלל ידרשו להתממשק עם המערכת הזו ישנו תמיד סיכוי (ופעמים רבות גבוה מכפי שנדמה לנו) שתידרש התממשקות כזו למערכות רבות אחרות, עצם קיומו של WebService המאפשר ביצוע אותן פעולות כמו ממשק המשתמש יוכל להוות אופציה סבירה. עם זאת חשוב להדגיש כי במקרים בהם מדובר על כמויות גדולות מאד של מידע ייתכנו בהחלט בעיות של ביצועים היות ובכ"ז מדובר על SOAP. אבל גם במקרים כאלו, אם יצרן התוכנה אינו זמין וגם אין לך ממשק WebService אין לך למעשה שום דרך לממשק את המערכת למערכות אחרות, אם יש לך WebService שמסוגל לבצע כל מה שהמשתמש יכול, תוכל לבנות ממשק קישור גם אם איטי ולהריץ אותו במועדים קבועים. כמובן שאם יצרן התוכנה עדיין זמין עדיף שתפנה אליו לבקשה של ממשק איכותי יותר – לדעתי עדיף להשתמש ב-WebService הנוכחי ורק להוסיף מתודה שמבצעת Paging של הנתונים בכדי להחזיר כל פעם חלק מהם. זאת משום שמספר המערכות אשר תומכות בסוג כזה של ממשק רק הולך וגדל כל הזמן.

בעיות הנוגעות לשמישות המידע במקרה אסון אצל ספק התוכנה
זו סוג של הבהרה של מה שכבר כתבתי קודם, אבל אולי שווה להזכיר את זה רק בכמה מילים: היות וכפי שכבר כתבתי קודם, ניתן לממשק בעזרת WebService מערכות שלא ממש חייבות להכיר זו את זו ולכן, גם במקרה שהספק כבר לא קיים יותר, הנתונים של הארגון למעשה לא בסכנה וניתן עקרונית להעביר אותם למערכת אחרת יחסית בקלות.

2 Comments

  1. שלום
    במסגרת עבודתי אני מפתח יישומים ל-web עם NET 2003.
    כיום בארגון בו אני עובד, רוצים להכניס לאפליקציות את נושא ה-AJAX.
    אנו מעוניינים להביא רשימת מדינות או טלפונים וכו'
    מה-server באמצעות AJAX כפי שציינתי.
    אני בניתי web service מרכזי לכלל האפליקציות בארגון אשר מחזיר את הרשימות הנ"ל והפניה אליו נעשית באמצעות AJAX
    ה- web master שלנו טוען שלא כדאי לעבוד כך ושכדאי שכל אפליקציה תחזיר את הרשימות הנ"ל באופן עצמאי ולא במקום מרכזי אחד כפי שציינתי ב- web service

    מה דעתך הן מבחינה של כתיבה נכונה מצד המתכנתים והן מבחינתו של ה-web master

    בברכה,
    אבי לוי

  2. אבי שלום,
    ראשית, שמחתי לקרוא את שאלתך, אם כי באיחור מה, שכן הייתי לצערי עסוק ברמה כזו שלא איפשרה לי להגיב קודם. ובכן, באשר לשאלתך, לדעתי שניכם צודקים במובן מסוים, כלומר: מחד גיסא, הגישה של שימוש ב-AJAX על מנת למשוך תכנים כגון רשימות שונות לדף באתר היא גישה מקובלת והגיונית שכן היא מאפשרת לדף ה-ASPX להציג תגובתיות למשתמש בזמן קבלת הנתונים (למשל Progress Indicator כלשהו) ובד בבד מאפשרת לעדכן אזורים בדף בהתאם לצורך וכך למעשה לחסוך זמן יקר בעת בניית הדף בשרת ה-ASPX. מאידך גיסא, ה-Web Master שלכם צודק אף הוא בכך שבניית אפליקציות ASPX (או כל אפליקציה שהיא) כך שכל פניה אליה תייצר סט של מספר פניות (למשל ב-AJAX על מנת למשוך רשימות שונות) עשויה (בהתאם לכמות הפניות הצפויה לאפליקציות ה-ASPX) ליצור עומס עצום על שרת ה-Web Service ואף לגרום לו להגיב באופן לקוי או לא להגיב כלל (בדומה למתקפת DoS). לדעתי, הפתרון צריך להיות שילוב בין השניים למשל באופן הבא: ה-Web Service ישתמש במנגנון ה-Output Caching של ASP.Net (על ידי ציון CacheDuration בתגית ה-WebMethod או שימוש ב-HttpContext.Cache.Insert) על מנת למנוע פניות לשליפת הרשימות ממאגר המידע בכל פעם, כמובן שאת משך הזמן יש להגדיר בהתאם לאופי הנתון (רשימת טלפונים משתנה בתדירות גבוהה הרבה יותר מרשימת מדינות), קוד ה-(Client Side (JS/VBS יפנה אל דף ה-ASPX עצמו מה שיאפשר לדף ה-ASPX למשוך את הנתון מה-Web Service ולשמור אותו אותו ב-Cache שלו עבור פניות ממשתמשים אחרים (לאחר שמשתמש אחד משך את הנתונים לאפליקציה הרלוונטית הם יהיו קיימים ב-Cache של ה-Web Service עבור אפליקציות אחרות וב-Cache של האפליקציה עבור משתמשים אחרים באותה אפליקציה), במקרים בהם תיתכן שליפה של הרשימות הללו יותר מפעם אחת באותו דף (למשל אם יש צורך למשוך אותם שוב במקרים שונים כמו בהצגת DIVים שונים) הייתי אפילו שומר את הערך בקוד ה-Client Side על מנת לחסוך בפניות אל דף ה-ASPX). כמובן שברשימות שמשתנות בתדירות מאד גבוהה – אם קיימות כאלו יהיה צורך למשוך אותן ישירות מה-Web Service במקרים כאלו הייתי משתדל לשמור אותן קטנות ככל שאפשר או מבצע Paging (משיכה של מספר שורות בכל פעם בהתאם ל-Scrolling של המשתמש). כמובן שבמקרים של עומס קיצוני על שרת ה-Web Service הייתי ממליץ על הקמת Cluster בעזרת Load Balancer כלשהו.

    מקווה שסייעתי לך ושהאתר היה לך לעזר – במידה ויש נושאים המעניינים אותך אשמח לדעת ולהשתדל לכתוב לגביהם בהמשך.
    יובל כליפא.

    admin

השאר תגובה