יישום רשת

יישום רשת (קרוי לפעמים גם "אפליקצית אינטרנט") (באנגלית: Web application) הוא יישום הבנוי במודל שרת–לקוח ונגיש דרך רשת מחשבים, כגון רשת האינטרנט או אינטראנט. לרוב, יישומי רשת משתמשים בדפדפן כתוכנת לקוח, והם מורכבים מדפי אינטרנט דינמיים המסתמכים על תוכנה שמורצת הן בצד השרת והן בצד הלקוח. בדרך כלל, בצד השרת מתבצע מרבית עיבוד הנתונים ויצירה דינמית של התוכן שנשלח להצגה בצד הלקוח (הדפדפן). בצד הלקוח, הדפדפן מפרש ומריץ את קוד ה־CSS, HTML ו־JavaScript שהתקבל מהשרת, מציג את התוכן, ושולח את הקלט מהמשתמש חזרה לעיבוד ואחסון על השרת.

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

היסטוריה

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

לעומת זאת, יישומי רשת משתמשים במסמכים הנכתבים בפורמט סטנדרטי, בשפות כגון HTML ו־JavaScript, אשר נתמכות על ידי מרבית הדפדפנים. ניתן להסתכל על יישומי רשת כעל גרסה מיוחדת של תוכנה הפועלת במודל שרת–לקוח, שבה תוכנת הלקוח מוּרדת למחשב הלקוח בזמן הביקור בדף האינטרנט הרלוונטי, תוך שימוש בפרוצדורות סטנדרטיות כמו בקשות HTTP. עדכון תוכנת הלקוח יכול להתבצע בכל ביקור מחדש בדף האינטרנט. בזמן התחברות, הדפדפן מפרש ומציג את הדפים ומשמש כלקוח האוניברסלי עבור יישום הרשת.

בימים המוקדמים של רשת האינטרנט, כל דף אינטרנט נפרד היה מועבר ללקוח כמסמך סטאטי, אבל רצף הדפים יכול היה לספק חוויה אינטראקטיבית. הקלט מהמשתמש היה מוחזר אל השרת דרך אלמנטים של טפסים המוטמעים בתוך שפת התגיות של הדף.
בשנת 1995, חברת נטסקייפ הציגה שפת תסריט לצד הלקוח בשם JavaScript, אשר מאפשרת למתכנתים להוסיף אלמנטים דינמיים לממשק המשתמש שרץ בצד הלקוח. כך, במקום לשלוח נתונים אל השרת ואז לקבל דף אינטרנט שלם, התסריטים המוטמעים בדף האינטרנט שהתקבל מהשרת היו יכולים לבצע משימות שונות, כגון בדיקת תקינות של הקלט, או הצגה והסתרה של חלקים מהעמוד.
בשנת 1996, חברת מקרומדיה הציגה את Flash, נגן של הנפשה וקטורית, הניתן להוספה לדפדפנים כתוסף, מה שאפשר להטמיע הנפשות בדפי אינטרנט. יישום זה נתן אפשרות להשתמש בשפת תסריט נוספת בשם ActionScript על מנת לתכנת אינטראקציות בצד הלקוח, בלי הצורך ליצור קשר עם השרת.
בשנת 1999, רעיון יישום הרשת הוצג בשפת Java, בגרסה 2.2 של מפרט Servlet. באותו זמן JavaScript ו־XML כבר פותחו, אבל המושג Ajax טרם הוטבע, והאובייקט XMLHttpRequest הוצג רק לאחרונה בדפדפן אינטרנט אקספלורר 5, כאובייקט ActiveX.

מפות Google הוא יישום רשת של חברת גוגל המציג מפות ותצלומי לוויין. זוהי דוגמה טובה ליישום שעושה שימוש נרחב בטכניקת Ajax

בשנת 2005 הוטבע המושג Ajax, ויישומים כמו Gmail התחילו להפוך את צד הלקוח שלהם ליותר ויותר אינטראקטיבי. כעת סקריפט בדף האינטרנט היה מסוגל ליצור קשר עם השרת לצורך אחסון או קבלה של נתונים, בלי הצורך להוריד דף אינטרנט שלם.
בשנת 2010 החל השימוש ב־HTML5, גרסה חדשה של שפת HTML, המספקת יכולות גרפיקה ומולטימדיה, ללא צורך בהתקנה של תוספים בצד הלקוח. HTML5 העשירה גם את התוכן הסמנטי של המסמכים. ממשקי תכנות היישומים (APIs) וה־DOM לא היו יותר תוצרים שבדיעבד, אלא הפכו לחלקים בסיסיים במפרט של HTML5. ממשק תכנות היישומים WebGL סלל את הדרך לגרפיקת תלת-ממד מתקדמת המבוססות על אלמנט ה־canvas של HTML5, ועל שפת JavaScript. לכל אלה חשיבות רבה ליצירת יישומי אינטרנט עשירים, שאינם תלויים בסוג הדפדפן או הפלטפורמה.

חוויית משתמש

באמצעות טכנולוגיות כמו Java, JavaScript, DHTML, Flash, Silverlight וטכנולוגיות אחרות, ניתן לקבל שירותים כגון ציור על גבי המסך, השמעת צלילים, גישה למקלדת ולעכבר, תמיכה בפעולות "גרור ושחרר", ועוד. מפתחי web משתמשים לעיתים קרובות בפונקציונליות של סקריפטים לצד הלקוח, במטרה ליצור חוויה אינטראקטיבית שאינה דורשת טעינה מחדש של הדף. בשנים האחרונות פותחו טכנולוגיות חדשות לצורך תיאום בין הסקריפטים בצד הלקוח לבין טכנולוגיות צד־שרת כמו PHP. טכניקה לפיתוח web בשם Ajax, אשר משתמשת בשילוב של כמה טכנולוגיות שונות, היא דוגמה לטכנולוגיה אשר משמשת ליצירת חוויית משתמש אינטראקטיבית יותר.

מבנה

בדרך כלל יישומי רשת מחולקים ליחידות לוגיות הנקראות "שכבות" (באנגלית: tiers), וכל שכבה מתמחה בתפקיד אחר. להבדיל מיישומים מסורתיים המורכבים רק משכבה אחת אשר רצה על גבי מחשב הלקוח, יישומי רשת מובילים מטבעם לעבודה במודל של ארכיטקטורה רב-שכבתית. אף על פי שקיימות אפשרויות שונות רבות, המבנה הנפוץ ביותר לעיצוב יישומי רשת הוא מבנה שלוש השכבות. בצורתו הנפוצה ביותר, מבנה שלוש השכבות מורכב מהשכבות הבאות: שכבת הצגה (presentation), שכבת הלוגיקה העסקית (business logic), ושכבת אחסון הנתונים (data storage).

הדפדפן נמצא בשכבה הראשונה והוא משמש להצגת התוכן למשתמש. בשכבה האמצעית (נקראת גם שכבת הלוגיקה העסקית או "שכבת היישום") נמצא שרת HTTP שעובד בתיאום עם מנוע ליצירת דפי אינטרנט דינמיים. לרוב, יצירת הדפים מתבצעת על ידי אחת מהטכנולוגיות הבאות: ASP, ASP.NET, CGI, ColdFusion, JSP, PHP, Perl, Python, Ruby on Rails. בשכבה השלישית נמצא בסיס נתונים המשמש לקבלה ואחסון של נתונים. סדר הפעולות הכללי הוא: הדפדפן שולח בקשות לשרת שמהווה את שכבת הלוגיקה העסקית, והוא משרת אותן באמצעות תשאול ועדכון של בסיס הנתונים, ולבסוף יוצר ושולח את התוכן חזרה להצגה בדפדפן.

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

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

מודל עסקי

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

במודל מחשוב הענן, יישומי רשת משמשים במתכונת (Software as a Service (SaaS — תוכנה כשירות. ישנם יישומים מסחריים המסופקים לארגונים במתכונת SaaS, בתמורה לתשלום קבוע או תלוי־שימוש. יישומי רשת אחרים מוצעים בחינם, ומספקים הכנסות בדרך כלל דרך פרסומות המופיעות בממשק של היישום.

פיתוח

קיימות תשתיות (Frameworks) רבות לפיתוח יישומי רשת, אשר מסייעות לפיתוח תוכנה זריז (Rapid application development), בכך שהן מאפשרות למפתח להגדיר תיאור ברמה הגבוהה (high-level) של התוכנה. בנוסף לכך קיימת האפשרות לפיתוח יישומים על גבי מערכות הפעלה אינטרנטיות, אם כי כיום לא קיימות פלטפורמות פרקטיות המתאימות למודל כזה.

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

סוגי יישומים

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

יתרונות

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

חסרונות

מבחינת נוחות השימוש וחוויית המשתמש שהם מספקים, יישומי רשת בדרך כלל יהיו נחותים לעומת תוכנות לקוח "עשירוֹת" (rich client), שאינן מסתמכות על חיבור לשרת לצורך ביצוע הפונקציונליות שלהן. (ראו: שרת–לקוח).
יישומי רשת דורשים תאימות מוחלטת מצד הדפדפנים. אם יצרנית דפדפנים מסוימת תחליט שלא לממש שירות (feature) מסוים, או תנטוש פלטפורמה או מערכת הפעלה מסוימת, דבר זה עלול להשפיע על מספר עצום של משתמשים.
יישומי דפדפן מסתמכים על קבצים הנמצאים על גבי שרתים מרוחקים הנגישים דרך האינטרנט. כתוצאה מכך, כאשר קיימת הפרעה בחיבור, לא ניתן להשתמש יותר ביישום. עם זאת, יישומים המשתמשים באפשרויות הקיימות ב־HTML5, כמו offline web application caching, ניתנים להורדה והתקנה מקומית לצורך שימוש במצב לא מקוון.
יישומי רשת תלויים לגמרי בזמינות השרת שמספק את היישום. אם החברה שפיתחה את היישום פושטת רגל והשרת שלה נסגר, למשתמשים אין יותר לאן לפנות. תוכנה מסורתית המותקנת על גבי המחשב ממשיכה לפעול גם לאחר הפסקת פעילותה של החברה שפיתחה אותה (אם כי לא יהיו עבורה יותר עדכונים או שירות לקוחות).
לחברה המפתחת יש שליטה חזקה בהרבה על התוכנה ואופן הפעולה שלה. החברה יכולה לשחרר תכונות חדשות בכל עת שתרצה, אפילו אם המשתמש יעדיף תחילה לחכות עד אשר כל הבאגים יטופלו לפני שיחליט לשדרג את התוכנה. לעיתים קרובות האפשרות לדלג על גרסה חלשה של התוכנה אינה קיימת. החברה עלולה לדחוף למשתמשים שירותים שאינם רצויים מבחינתם, או לקצץ בעלויות על ידי צמצום רוחב הפס. חברות ינסו לשמור על לקוחותיהן מרוצים, אבל למשתמשי יישומי רשת יש פחות אפשרויות במקרים כאלה אלא אם כן קיימת חברה מתחרה אשר מציעה מוצר טוב יותר ואפשרות נוחה למעבר אליה.
תאורטית החברה יכולה לעקוב אחרי כל דבר שהמשתמש עושה, דבר העלול להוביל לבעיות פרטיות.

ראו גם

קישורים חיצוניים

מדיה וקבצים בנושא יישום רשת בוויקישיתוף