לאחרונה, בעקבות גל של רכישות של מערכות מידע חדשות נתקלתי לא פעם באנשי מכירות שניסו לשכנע אותנו לרכוש את המוצר שלהם בעזרת הטענה השחוקה ביותר לגבי מערכות מבוססות דפדפן: "זו אפליקציית Web – היא לא צריכה שום התקנה בתחנת הקצה". לנו, כמנהלי רשת טיעון כזה אכן נשמע קוסם למדי, מערכת שלא צריך להפיץ אותה לתחנות… האמת הייתה הרבה פחות אסתטית והרבה יותר כואבת, התקנות של רכיבים כלשהם בתחנות, בעיות רוחב פס, תקלות שונות בזמני התגובה של המערכות הללו ועוד.
בעיניהם של מנהלים רבים ואף אנשי מחשוב רבים, ממשקי משתמש מבוססי דפדפן (Web-ים) נתפסים כממשקי משתמש מהמתקדמים ביותר, ולמעשה מהווים שיקול משמעותי ולפעמים מכריע בעת בחירת חלופה כזו או אחרת. כמו כן, מנהלים רבים מאמינים באמת ובתמים כי ממשקי משתמש מבוססי דפדפן מחליפים אט אט את ממשקי המשתמש מבוססי החלונות, האמת היא שאין זה לגמרי מדויק ולא זו בלבד אלא שלממשקי משתמש קיימות בעיות מורכבות אשר פתרונן לעתים קרובות אינו מספק. במאמר זה אפרט את הבעיות העיקריות שאיתן נאלצים להתמודד מתכנני ממשקי משתמש מבוססי דפדפן, את הפתרונות הפוטנציאליים כמו גם את נקודות החולשה של ממשקים מסוג זה.
ובכן, על מנת להבין אל נכון את הבעיות אשר איתן נאלץ להתמודד מתכנן של ממשק משתמש מבוסס דפדפן עלינו לחזור מעט לאחור בזמן. בשנת 1990 פיזיקאי בריטי בשם טים ברנרס לי (היום סר טים ברנרס לי) הגדיר את מפרט ה-HTML הראשון (כיישום מסוים של תקן SGML) וכתב את הדפדפן הראשון כמו גם את שרת האינטרנט הראשון. כחלק מהגדרת ה-HTML הגדיר טים ברנרס לי את פרוטוקול התקשורת HTTP לצורך העברת מסמכי HTML בין השרת אל הדפדפן. ביומנו רשם טים ברנרס לי רשימה של שימושים שהעלה בדעתו עבור HTML, בראש הרשימה מופיעה "אנציקלופדיה".
זו למעשה הייתה פחות או יותר מהות רוב האתרים באותה תקופה – דפים שנועדו להציג מסמכים, מאמרים וספרות באופן שניתן יהיה לדלג מאחד לשני על-ידי קישורים בגוף הטקסט (Hyperlinks), היתרון הבולט במיוחד בפרוטוקול HTTP לעומת פרוטוקולים אחרים מקובלים באותה תקופה היה בכך שהוא היה Stateless מטבעו כלומר הוא אינו מחייב את השרת לשמור מידע לגבי לקוחותיו בין הפניות השונות, המשמעות היא שבכל פניה לשרת האינטרנט השרת מזהה את התחנה הפונה מחדש ומיד לאחר שהשרת ביצע את הבקשה הוא מנתק את התקשורת עם התחנה, כך מתאפשר לשרת לתקשר עם מספר גדול בהרבה של תחנות קצה לעומת פרוטוקולים המוגדרים כ-Stateful (ההפך מ-Stateless). יתרון בולט זה, כמו גם הקלות הרבה של כתיבת מסמכי HTML סייעו לפרוטוקול זה להיות אחד מהפרוטוקולים המהווים את הבסיס לאינטרנט כפי שאנו מכירים אותו היום.
כמעט עם תחילת צמיחת ה-World Wide Web החלו לצוץ אתרים בעלי תוכן יותר ויותר בידורי, אשר החל בפרסומות והמשיך אל משחקים מקוונים, הבעיה של אותם מתכננים הייתה תמיד אותו "יתרון" עליו דיברנו קודם: אם בכל פניה לשרת התחנה מזוהה מחדש, איך יהיה אפשרי לדאוג לכך שלאחר שתבצע כניסה עם שם משתמש וסיסמא לאתר הבנק שלך, האתר ימשיך לזכור מי אתה גם כאשר תבקש לצפות בדף אחר – פירוט חשבון למשל…? בנוסף, כתוצאה מהדרישה לתוכן בידורי יותר צפה ועלתה בעיה נוספת – כיצד יהיה ניתן להשתמש בטכנולוגית ה-HTML שנבנתה על מנת להציג תוכן סטטי לחלוטין (כמו אנציקלופדיות) על מנת להציג תוכן בידורי, אינטראקטיבי?
במקביל לבעיות אלו, חברות רבות קמו וגדלו עם התפתחות הבועה האינטרנטית, חברות אלו השכילו להבין שמה שטוב בשביל כל משתמשי האינטרנט יהיה בהכרח שימושי עבורן בתוך כותלי החברה. כך החל השימוש באינטראנט, ככל שהלך והתרחב השימוש בפורטלי אינטראנט ובאתרי אינטרנט הלך וגבר הצורך במערכות מידע שלמות שיתפקדו במסגרת כזו, אך בד בבד הלכה והתחדדה בעייתיות נוספת – מערכות רבות עבדו באופנים המוגדרים כ-Near real time או אפילו מערכות פשוטות יחסית כגון מערכת לניהול דואר אלקטרוני אינטרנטי צריכה להיות מסוגלת להציג בכל רגע נתון את ההודעות הממתינות למשתמש כאשר היא נדרשת כמובן להתעדכן כאשר מתקבל דואר חדש וכדו', כיצד יהיה ניתן ליישם פעילויות מסוג זה כאשר פרוטוקול HTTP בנוי לטפל בדפי HTML שלמים? זאת ועוד, הדף נדרש להיראות שונה עבור כל משתמש, היה צריך מנגנון שיהיה מסוגל לייצר HTML שונה לכל משתמש.
היות וכאמור, פרוטוקול ה-HTTP ומבנה ה-HTML מעולם לא אופיינו על מנת לתת מענה הולם לדרישות אלו, כל הפתרונות הקיימים כיום לבעיות אלו נותנים מענה מסוים לבעיה הרלוונטית אך סובלים מבעיות שונות, להלן סקירה קצרה של הפתרונות השונים לבעיות אלו:
- דפי אינטרנט דינאמיים – שימוש בתוכנה המופעלת בשרת המארח את האתר על מנת לייצר דפי HTML ולשלוח אותם לתחנה, דוגמאות למנגנונים מסוג זה כוללות בין השאר את הטכנולוגיות הבאות: CGI, ASP, ASP.Net, PHP ואחרות. היתרון המשמעותי בשיטה זו הוא בכך שהיא מאפשרת יצירה של דף שונה עבור כל משתמש באתר. החיסרון המשמעותי הוא בכך שעבור כל פניה נוצר ונשלח ללקוח דף HTML שלם, הדבר בעייתי במיוחד כאשר נדרשים ליצור מספר גדול יחסית של פניות לשרת ביחידת זמן ובמיוחד כאשר הדפים המיוצרים דומים זה לזה. הטכנולוגיות הראשונות לייצור דפי אינטרנט דינאמיים הופיעו עוד בראשית שנות ה-90 (CGI) ואילו הטכנולוגיות האחרות (במיוחד ASP.Net ו-J2EE) ממשיכות לככב במערכות האינטרנטיות והאינטראנטיות של היום. בנוסף, חשוב להבין שטכנולוגיה זו לבדה אינה מסוגלת ליצור דף המכיל סרטון למשל. על מנת לעשות זאת יהיה צורך להשתמש בטכנולוגיות אחרות בנוסף. היתרון הגדול בשימוש בה הוא שהתחנה למעשה איננה משחקת תפקיד משמעותי ולכן לא נדרשת בה התקנה כלשהי.
- ActiveX – טכנולוגיה שפותחה ע"י חברת מייקרוסופט ואשר מאפשרת הפעלה של כל רכיב תוכנה שפותח בה ישירות מתוך דף אינטרנט או אינטראנט. מכאן גם נובעת הבעייתיות שלה: הרכיב שמגיע בדף האינטרנט למעשה מותקן בתחנה ומורץ משם, בנוסף, היות ורכיב תוכנה זה יכול עקרונית לבצע כל דבר שתוכנית חלונאית יכולה לבצע, ניתן בקלות לייצר וירוסים או רושעות (Malware) ולאפשר למשתמשים תמימים להיכנס לאתר והם יורדו ויבוצעו. היתרון הבולט מבחינת התכניתן הוא כמובן זה שבעצם ב-ActiveX ניתן לכתוב למעשה כל סוג של אפליקציה חלונאית כפי שתכניתן רגיל לעשות ולהפעיל אותה באמצעות דפדפן כביכול ללא התקנה. מבחינת מנהל הרשת זו התקנה לכל דבר ועניין ואם לא די בזה זו אפליקציה שיכולה להיות וירוס, Malware או רכיב אחר הכולל בתוכו קוד זדוני כלשהו. מסיבה זו בד"כ מנהלי רשתות מנסים למצוא דרכים לחסום התקנות מכל סוג בתחנות הקצה ולהתקין רק רכיבים מוכרים ובדוקים (למשל באמצעות MSI דרך GPO), במקרה כזה יהיה צורך "לארוז" את התקנת ה-ActiveX כקובץ MSI ולהפיצו כרגיל בתחנות.
- Flash/Silverlight – טכנולוגיות אלו נולדו על מנת לאפשר את כתיבתם של אתרים, פרסומות, סרטים ומצגות המכילים תוכן דינאמי ואינטראקטיבי מאד. החיסרון הבולט של טכנולוגיות אלו הוא בעיקר זמן הטעינה הארוך יחסית. חשוב להדגיש כי עצם השימוש ברכיבים המיישמים טכנולוגיות אלו אין פירושו שהאתר יוכל באופן כלשהו לזהות משתמשים ו/או לשנות את תוכן הדף בהתאם.
- Client side scripting – על מנת לאפשר לדף להיות מעט יותר אינטראקטיבי, תכניתנים משתמשים בקטע קוד המגיע כחלק מדף ה-HTML אל הדפדפן ומבוצע על ידו במחשב הלקוח. קוד זה מורץ בסביבה מוגנת אותה מייצר הדפדפן (ואשר מכונה Sandbox) על מנת למנוע מקטע הקוד הזה גישה אל הקבצים וההתקנים הקיימים במחשב. חשוב להבין כי עצם השימוש בטכנולוגיה זו אינה מאפשרת ביצוע וידוא זהות הפונה (Authentication) מול מסד נתונים כלשהו או אפילו להמתין לפניה ממחשב אחר.
- (AJAX (Asynchronous Javascript And XML – זו לא בדיוק טכנולוגיה אלא יותר מיזוג של 2 טכנולוגיות לצורך מתן פתרון גנרי, הרעיון הבסיסי הוא שימוש ב-Client side scripting (במיוחד Javascript) על מנת לפנות לשרת כלשהו בעזרת העברת מסרי XML (למשל ל-WebService כלשהו) באופן אסינכרוני על מנת לעדכן חלקים מהדף (בדרך כלל בעזרת HTML DOM) תוך כדי טעינת הדף ולאחר הצגתו. באופן כזה, בשילוב עם דפי אינטרנט דינאמיים ניתן לייצר אתר אינטרנט אשר נראים שונה עבור כל אחד ממשתמשי האתר ובכל זאת לאפשר לדף להתעדכן באופן דינאמי לאחר הצגתו למשתמש (למשל במערכת דואר אלקטרוני יוכל הדף למשוך את רשימת המיילים למשתמש אחת לפרק זמן מוגדר וללא צורך בעדכון של הדף כולו, להציג את המיילים החדשים.
ניתן לסכם ולומר שלמרות שטכנולוגיות האינטרנט תוכננו באופן שלא מספק מענה הולם לצרכים מהן כיום, על ידי שילוב של מספר טכנולוגיות ניתן להשיג במקרים רבים מענה סביר, אך עם זאת חשוב להבין שככל שמתקרבים מבחינת יכולות המערכת לאלו הקיימים בתכנות החלונאי יופיעו גם אותן בעיות ותיקות של הפצת התכנית למשתמשים (אם היא כתובה כ-ActiveX למשל) ושל אבטחת המידע (אם מגיעים ב-https לאתר המכיל פקד ActiveX אותו פקד יכול טכנולוגית להעביר את הנתונים הלאה באופן שאינו מאובטח כלל או אף להשיג מידע מהתחנה במקרים מסוימים ללא כל הצפנה).