תרומותיו של אדם בוזוורת' (Adam Bosworth ) לפיתוח וקידום שירותי הרשת (Web Services) החלו לפני שנולד הביטוי "שירותי רשת". הדבר נובע מכך שבהיותו מנהל בכיר במיקרוסופט – היה ממתכנני הסטנדרט XML. במהלך עבודתו, הוא מילא תפקיד כמנהל הכללי של תוכן הרשת במיקרוסופט (ואחראי להגדיר אסטרטגיית XML רחוקת טווח) וכל זאת בנוסף להובלת הפיתוח של מנוע ה- HTML בדפדפן "אינטרנט אקספלורר", גרסאות 4 ו- 5. כיום, כארכיטקט ראשי וסמנכ"ל פיתוח בחברת "BEA Systems", בוזוורת' מעורב בצורה יותר ישירה בעתיד שירותי הרשת.
בכדי לקבל מבוזוורת' הבנה טובה לגבי האפשרויות והסכנות שהוא צופה, קירק מקיוסיק (Kirk MCkusick) – בעבר מנהל קבוצת הפיתוח מערכות מחשב, באוניברסיטת ברקלי בקליפורניה – התבקש לשאול אותו מספר שאלות בנוגע לתפיסתו את שירותי הרשת. בנוסף לפיקוח על פיתוח BSD4.3 ו- BSD4.4. מקיוסיק ידוע בשל עבודתו על מערכות זיכרון וירטואלי ומערכות קבצים מהירות – ובשנים האחרונות הוא מוכר כאחד ממנהיגי תנועת הקוד הפתוח.
רבים מדברים על שירותי הרשת, אך קרוב לוודאי שאינם מתכוונים לאותו הדבר. כיצד אתה היית מגדיר "שירותי רשת" ?
המונח "שירותי רשת" מתייחס לארכיטקטורה המאפשרת ליישומים לדבר האחד עם השני. נקודה. סוף פסוק.
מובן. אז מה שירותי הרשת אינם ?
נכון ששירותי רשת אינם מתאימים לכל מצב של תקשורת B2B (תקשורת בין עסקים – Business to Business) כיום, מכיון שתקשורת אמינה ומאובטחת דורשת למעשה דרך אחרת. וברור ששירותי רשת אינם מאפשרים כעת ביצועים טובים של שידור למספר רב של מקומות, משמע שאינם מספקים את פתרון זמן-אמת הטוב ביותר להעברת מידע. למעשה, בתכנון שירותי הרשת מעסיקה אותנו שאלה בסיסית למדי.
ומהי?
ברשת יש מספר רב של יישומים שצריכים לדבר האחד עם השני, כלומר עברנו מעולם דו-דרגתי (two tier) לעולם N-דרגתי (n-tier), ושאלת המפתח היא: מהי הארכיטקטורה הנכונה לתקשורת בעולם N-דרגתי? העלנו שלושה עקרונות בסיסיים, אליהם נצמדנו כמו דבק, ואלו הנחו את גישתנו אל תכנון שירותי הרשת מן ההתחלה. עקרונות אלה תקפים גם היום, וזו הסיבה, לדעתי, ששירותי הרשת מתחילים לתפוס תאוצה.
ומהם שלושת עקרונות אלו?
לא כולם אינטואיטיביים. הראשון, כמובן, קשור ליעילות תקשורת. נניח שדרך הרשת, אתה רוצה למשוך מידע מתוך סט של רשומות SQL תקינות המכילות מאות ערכים שונים. ברור שאינך רוצה לעבור קודם על השדה הראשון של הרשומה הראשונה, השדה השני של הרשומה הראשונה וכן הלאה, עבור כל ערך. הדבר לא יעבוד עם בסיס נתונים מקומי, על אחת כמה וכמה כשמדובר ברשת. זאת מפני שבגישה כזו, בסיס הנתונים יקרוס בתוך זמן קצר. ביישום שרת/לקוח, בסיס הנתונים שומר על קשר קבוע, מבוסס TCP/IP, עם הלקוח. אך כשמדובר ברשת ה- Web, לא ניתן להשיג זאת. במקום זאת, קיימים לרשותנו פרוטוקולים חד כיווניים (Stateless protocols). לכן שליחת מידע הלוך ושוב הופכת יקרה יותר. בנוסף לכך, בניגוד למקרה של בסיס נתונים מקומי בו ע"פ רוב לא קיימת בעיית שינוי פלטפורמה, מפני שקיים בשני הצדדים קוד המוודא שחבילות המידע המוחלפות יתקבלו בסדר הנכון – פה בעיית התקשורת בין יישומים בפלטפורמות שונות היא יותר גדולה.
יש לשים לב גם לנושא שלמות המידע. בסיס נתונים יכול לטפל בבקשה בתוך זמן קצר, אם מדובר בקונפיגורציית שרת/לקוח. אך אם מדובר ביישום הניגש לבקש מיישום אחר 1000 דברים שונים ב- 1000 נקודות זמן שונות, הסיכויים שהמידע יהיה שלם הם די קלושים. הדבר ההגיוני לעשות הוא לבקש את כל המידע הרצוי (למשל, את כל התיק הרפואי) באותו זמן. כך אנו מצטמצמים לבקשה אחת הנשלחת דרך הרשת. ולאחר מכן, בתוך המערכת של בית החולים, ניתן למשוך את כל המידע הדרוש ולמסרו כחבילה אחת. מודל זה יעיל מאוד עבור רשת האינטרנט, ואינו דורש תקשורת דו כוונית. כעקרון, אם לא ננקוט בגישה זו, ייתכן ולא נוכל להרחיב את המערכת בעתיד (הדבר תקף הן בעולם בסיסי הנתונים והן בעולם היישומים).
עד כה דיברנו על תקשורת ויעילות צד השרת. מהם שני העקרונות האחרים אותם הזכרת קודם?
השני עוסק באי-תלות בין זוגות (למשל, שרת ולקוח). חשוב על כל היישומים הקיימים כעל ים של בועות. נוכל לומר שכל ניסיון לשלב יישומים יחד הוא למזג מספר בועות יחד, ואפילו ליצור בועות חדשות בעזרת המיזוג. עם הזמן הבועות משתנות, מפני שאנשים מפתחים ומשפרים את היישומים. הם עורכים מחדש, מרחיבים, משנים. הם יכולים אף להחליף חלקי תוכנה שלמים או מערכות הפעלה. לא כל הבועות משתנות, אך אט אט תוכל לראות הרבה תנועה. ואם הארכיטקטורה שלך אינה גמישה מספיק ואינה מאפשרת ליישומים להמשיך לתקשר האחד עם השני למרות השינויים, הארכיטקטורה נכשלת בתפקידה. המשמעות היא, שכל שינוי וכל יישום מהווה פוטנציאל לאי-יציבות בכל המערכת. לכן תוכל להיות בטוח שהיא לא תתאים לשילוב יישומים, אלא אם היא מסוגלת לטפל בצורה טובה ואמינה בשינויים.
לדוגמא, נכשלנו במבחן מחשוב השרת/לקוח. זאת מפני שאם בלקוח ישנו קוד המתקשר עם בסיס נתונים, קיימת סבירות גבוהה שבעת שינוי בסיס הנתונים – נצטרך לשנות את הקוד בלקוח – וכך גילה גם כל מי שבנה יישום שרת/לקוח, זמן קצר לאחר שביצע שינויים בשרת…
בעולם בו חיינו בעבר, קוד של יישום לקוח היה בתחנות העבודה של המשתמשים, כך שבמקרה שבו הוא הפסיק לתפקד היינו בבעיה – שלמעשה לא הייתה נוראית כל כך: היית לוקח קוד חדש, מפיץ לכל תחנות העבודה והחיים ממשיכים. אך פה מדובר ביישומים המופצים ברשת האינטרנט, ואין דרך בה תוכל להפיץ קוד חדש לכל יישום, רק מפני שהחלטת לשנות את הדרך בה היישום פועל. לכן עלינו לתכנן יישומים בצורה כזו, שלא יהיו תלויים בצורת המימוש של יישומים אחרים. עלי להיות בטוח בכך, שאוכל לשנות את דרך המימוש בלי להשפיע על אחרים. המצחיק הוא, שהנחנו שבעזרת מחשוב מונחה-עצמים, פתרנו בעייה זו ע"י הוספת תכונות ויכולת עטיפה (encapsulation). כך שלמעשה לא יכולת לדעת איך המידע מאוחסן, מפני שהוא היה חבוי, והגישה אליו היתה באמצעות שיטות מוגדרות מראש. ואנו הנחנו שהדבר יגן עלינו מפני שינויים בצורת המימוש.
הנחנו גם שנוכל להתמודד עם שינויים, כי היה לנו מנשק שחשבנו שיתמוך בדרכים הישנות והחדשות, עם התפתחות האובייקט. לכן, אמרנו לעצמנו בשביעות רצון: הצלחנו לפצח זאת! יש לנו מודל המסוגל לספוג שינויים ולהתפתח.
אך גילינו שטעינו, לא כן?
כן, התברר שלמעשה ישנן שתי בעיות. אובייקט הוא דבר מורכב עד מאוד, ונסיוננו (שנרכש בדרך הקשה) לימד שלא ניתן לקרא לכל שיטה (method) או לבצע השמה של ערך בכל זמן שנרצה. מגוון חוקים מכתיבים לנו כיצד לדבר עם אובייקט – ומספקים כוריאוגרפייה שחייבים לעמוד בה. אם תנסה אי פעם לשנות את הסדר, תגלה שדברים אינם עובדים כלל; ואף אחד למעשה לא יודע את החוקים במלואם, בגלל מורכבות ויכולתם הרבה של המנשקים, שקשה לתאר אותם ואף קשה מזאת להבינם. מצב בו אינך מכיר את החוקים, דומה למצב בו שכרת בית אך שטר המכירה מודפס באותיות כה זעירות, שלא תוכל לקרא או להבין דבר.
אלו חדשות רעות. במדעי המחשב היו לנו שתי התפתחויות עיקריות ב- 20 השנים האחרונות: מחשוב שרת/לקוח ומחשוב מונחה עצמים. ושניהם נכשלו במבחן זה – וזה המבחן שעלינו לעבור אם אנו מעוניינים בארכיטקטורה המתאימה לשילוב יישומים.
אז מה עושים?
התבוננו על דוגמא אחרת המוכרת לנו – דפדפן האינטרנט, כמובן. הדבר בא לי בטבעיות, מפני שתפקדתי כראש צוות ב- Microsoft שהיה אחראי לבניית מנוע ה- HTML של הדפדפן Internet Explorer בגרסאות 4 ו- 5. מסתבר שדפדפן הוא דוגמא יוצאת דופן להצלחה של יישום, המתקשר עם יישומים אחרים המכונים "אתרי אינטרנט" – שכמובן נוטים להשתנות כל הזמן. למעשה, בסיסי הנתונים, המחלקות, מערכות ההפעלה ובעצם – כמעט כל דבר הקשור באתר אינטרנט – מובטח שישתנה במשך הזמן, אך אנו עדיין מצפים שהדפדפן יעבור בצורה מושלמת מול האתר. הדפדפן אינו יודע כמעט דבר על הדרך בה ממומש האתר. הוא יודע שני דברים: הפרוטוקול בו משודר המידע, HTTP, ואוסף של תבניות בהם מגיע המידע (ובפרט HTML). וכל עוד האתר תומך בפרוטוקול ובמספר תבניות ידועות, הדפדפן ימשיך לתפקד כרגיל.
סיבה נוספת להצלחת הדפדפן היא קלות השימוש. HTTP הוא פרוטוקול תקשורת "נוראי". הוא לא יעיל, הוא מגושם. אך הוא קל למדי. כל אחד יכול לממש אותו, מה שהופך את הרשת לדמוקרטית. אין אף אחד בשליטה, והתוצאה היא שמספר מימושים הגיעו למצב שבו כולם החלו להשתמש בהם, מפני ש- "היי, זה עובד, ונראה שכל האחרים משתמשים בזה…" – והנה, קיבלת כתוצאה מכך אפקט של רשת.
אז בחנו את ארכיטקטורת הדפדפן והבנו שעלינו להשתמש במודל דומה כדי ליצור פרוטוקול עבור שירותי הרשת – שלבסוף נודע כ- SOAP. כמו כן יש לשים לב לתבניות הנלוות לפרוטוקול, המתוארות ע"י יישום המכונה WDSL, שתפקידו הוא לתאר הודעות XML.
למה בחרתם ב- XML ?
בחרנו ב- XML מפני שהוא מספק דרך טובה לתאר מסרים שונים. שאלנו את עצמנו מה יהיה קל וגמיש דיו כדי שיוכל להתמודד עם הכל, החל ממסרים בעלי מורכבות מבנית (כמו הזמנת מוצר) וכלה במסרים פשוטים יותר (דוגמת פתק שכותב הרופא יחד עם מעט מידע על החולה).
XML מספק פתרון המאפשר תקשורת יעילה. SOAP ו- WSDL, בינתיים, מספקים את אי התלות (loose coupling) בין צמדים לו אנו זקוקים. אך הדבר נכון רק שכאשר אתה משנה את היישום שלך אתה מוודא שאף אחת מהודעות ה- XML לא תשתנה, מפני שזהו המקום בו נוסד החוזה שלך עם העולם החיצון. תאר לעצמך, ששיניתי את אתר האינטרנט שלי כך שאינו כתוב יותר ב- HTML. נניח, למשל, שכתבתי אותו ב- WML. הדפדפן לא ישמח כל כך במקרה זה… ובאופן דומה, אם הייתי משנה יישום כך שלא יעמוד יותר בדקדוק של XML, היישומים האחרים איתם אני מתקשר לא יתפקדו בצורה נכונה. לכן, הדבר בעל החשיבות העליונה הוא WSDL, ולא הקוד עצמו.
העלתי זאת פשוט מפני שרבים בונים פתרונות ע"י שירותי רשת כביכול, ועושים זאת בדרך הלא נכונה. הם גורמים לך לבנות קוד משלך, ולאחר מכן יוצרים מסרי XML ע"פת תיאור של אותו קוד, אך, במוקדם או במאוחר, הקוד יעבור שינויים, וכשזה יקרה – כל הודעות ה- XML הנוצרות באופן אוטומטי עלולות לגרום נזקים.
ובכן – זה בהחלט מכסה את נושא האי-תלות. הזכרת בדבריך עקרון שלישי?
כן, והוא נוגע בנושא של חוסר סנכרון. בעולם האמיתי, עליך להיות מוכן למאורעות שיקרו כאשר יישומים מסויימים אינם זמינים. ולכך ישנם שלוש סיבות בסיסיות: הראשונה – יישומים מפסיקים לפעול, מסיבות שונות. כולם יודעים שלא קיים יישום הזמין 100% מהזמן. חברת ההשקעות שלי, לדוגמא, אינה מספקת לי מידע על המתרחש בתיק ההשקעות לי בין חצות לשעה שתיים לפנות בוקר בימי שבת.
וכשאתה מוצא את עצמך מתמודד עם דבר שכזה, אינך יכול לשבת בחוסר מעש, ולהמתין ליישום שיחזור לפעולה. חייבת להיות דרך להתמודד עם העניין.
הבעייה הרצינית השנייה היא שיישומים מסויימים אינם מסוגלים להתמודד עם עומס נתון, מפני שרובם לא נכתבו בצורה שמאפשרת התמודדות עם עומסים בלתי צפויים. הסיבה שחברת BEA קיימת היא למעשה בגלל שרשת האינטרנט פתחה תיבת פנדורה של עומסים בלתי צפויים. כתוצאה מכך, קרוב לוודאי שתיתקל בצוואר בקבוק זמני מדי פעם. וכאשר תנסה ליצור עוד ועוד תהליכים ביישום היוצרים תקשורת עם השרת, הם בסבירות גבוהה – יחסמו. או אף גרוע מכך – היישום עצמו יקרוס. לכן, חיוני לזכור שרוב היישומים יכולים להתמודד עם מספר מוגבל של בקשות במסגרת זמן נתונה.
הגורם השלישי העיקרי לחוסר הזמינות הוא שמשתמשים לעיתים קרובות מבקשים מהיישום לבצע משימות שלוקחות זמן. ישנה סיבה לכך שהחנות המקוונת Amazon.com אינה יכולה לומר מיד אם הספר שהזמנת נשלח אליך – הרי מישהו חייב לגשת ולמצא את הספר. ייתכן מצב בו הספר אינו במלאי. לכן, כתוצאה מכך – התגובה שתקבל תהיה שהזמנתך נקלטה, ותו לא.
אם כך, איך אתה מתכוון לספק שירות כאשר היישומים אינם זמינים?
ברמה העקרונית, הארכיטקטורה שאנו בונים מבוססת מסרים. הבעייה הזו נלקחה בחשבון כאשר תכננו את שירותי הרשת. אחת מהסיבות לשימוש במסרי XML ובפרוטוקול SOAP היא שהם יכולים לפעול לא רק בתצורה סינכרונית, אלא גם בתצורה מבוססת מסרים – לה אנו זקוקים כדי לממש תקשורת א-סנכרונית. וזהו אחד מעקרונות המפתח בגישה של BEA. אנו תומכים בתצורה סנכרונית וא-סנכרונית, מפני שאנו חושבים ששילוב מספר עצום של יישומים בסופו של דבר יהיה א-סנכרוני, ולו רק בשל העובדה שדרוש מנגנון חסין בפני עומסים בלתי צפויים, תקלות ביישומים ובעיות זמינות.
אינכם צריכים להיות גם א-סנכרונים, וגם חד כווניים (Stateless) ?
נכון – חד כווניים ככל שאפשר. אנו לא תמיד בונים בצורה חד כוונית מפני שישנם מקרים בהם לא ניתן לעשות כן. למעשה אנו מעבירים את המשימה של שמירת מצב התקשורת מבסיס הנתונים אל מישהו אחר. בכל מקרה, אלו הן העקרונות עליהם חשבנו כאשר תכננו את שירותי הרשת. יותר ויותר אנשים מנצלים כבר את היתרון שבכך לצורך שילוב יישומים הדורשים תקשורת בינם לבין עצמם – כרגע מדובר ביישומים תוך ארגוניים, כאשר נושא האבטחה אינו מסובך מדי וישנם פרוטוקולים אמינים הזמינים למטרה זו.
לאחרונה אנו רואים גם שילוב יישומים בין ארגונים, ובתוך ששה חודשים עד שנה מהיום – לדעתי נראה אמצעי אבטחה מתקדמים יותר, יחד עם פרוטוקולים המרחיבים את SOAP לקבלת אמינות טובה יותר. למעשה, אני מצפה לראות שפורי אבטחה בעתיד הקרוב מאוד.
אני שמח שהזכרת את נושא האבטחה. האם ישנה ארכיטכטורה זמינה כיום? או לפחות מפת דרכים לכך המשקפת את היעדים אליהם אנו חותרים?
אכן ישנה ארכיטקטורה עבור נושא האבטחה, למעשה – תקן לכך יתפרסם בקרוב, ויתאר בפרוטרוט כיצד ארכיטקטורה זו תעבוד. יש לזכור שהתקן מודע לכך שכיום האבטחה עובדת בצורה מאוחדת (federated), ולא מרוכזת – דבר שרוב האנשים יעדיפו להתעלם ממנו. כלומר – המושג של מיקרוסופט של מקור אבטחה יחיד לכל טרנסאקציה (החלפת מידע) שמתבצעת בעולם הוא לא דבר שיתקבל באהדה ע"י רבים. ובנוסף לכך, ההסטוריה מוכיחה לנו שדברים נוטים ללכת לכוון ביזור, בכל נושא – בין אם אנו דנים בביולוגיה, פיסיקה או תוכנה.
ספר לנו עוד על מודל האבטחה המאוחד (federated).
הדבר הראשון שצריך לעשות כאשר מגיע בקשה לשירות רשת היא לוודא את הרשאות השולח, כלומר – לאשר שאכן הבקשה אכן הגיעה מאותו אדם שטוען ששלח אותה. ארכיטקטורת האבטחה החדשנית שלנו תומכת בכך. כמו כן, אתה מעוניין ביכולת פענוח – שהרי מסרי ה- XML ישמשו להעברת מסרים מוצפנים. אנו מאפשרים לאשר פעולות מסוימות על בסיס הרשאות שנוצרו קודם לכן. לכן, כשאתה מבצע אימות של מבקש הבקשה, עליך לדעת את תפקידו ולהשתמש במידע זה כדי להחליט אם הוא רשאי לבצע את הבקשה או לא. נסיוננו המר מראה לנו שאין מערכת אבטחה מושלמת. זו בעייה קשה מאוד. אך קרוב לוודאי שישנה ארכיטקטורה המתאימה לשירותי הרשת, ולשכבות XML ו- WSDL.
הדבר השני שאנו רואים היא גדילה מהירה בדרישה לריכוז המסרים לפני שליחה (message brokering) וניהול שירותי רשת. כאשר ארגונים פתחו את משאביהם בפני שירותי הרשת, עלתה השאלה כיצד לנהל את רשימת המורשים להשתמש בשירותים אלה. יתר כל כן, כיצד לבצע כניסה למערכת? כיצד לפקח על הפעילות המתבצעת? נושא השליטה והפיקוח הופך להיות בעל חשיבות מרובה, לכן נצפה בשנתיים הבאות לראות פעילות ענפה בפיתוח כלי ניהול שיאפשרו לארגונים שליטה טובה יותר בבקשות המתקבלות במערכת. ואנו נראה יותר ויותר מאלה, עד שהמידע הנלווה (metadata) יהיה בעל תפקיד מרכזי בכל הפעלה של יישום בין-ארגוני.
וכיצד BPEL משתלבת בתמונה?
מסתבר שכניסתן של תבניות מונחות מסרים יצרה דרישה לשליטה בתהליך זרימת העבודה (workflow). שפת BPEL מאפשרת ליצור תסריטים שישלטו בכך. להבנת החשיבות של שפה כזו, נתבונן בשפה Visual Basic כדוגמא. אחת מן היכולות החזקות של Visual Basic היא "מעצב הטפסים" (Form Designer) – בו כל אחד יכול להשתמש. מתכנת מערכת, או אפילו אדם שאינו מתכנת כלל, יכול ליצור יישום בקלות יחסית. באופן דומה, כדי לתכנן ולשלוט בזרימת התהליך, יש צורך בעורך ויזואלי שכל אחד יוכל להשתמש בו, אך עם זאת בעל יכולות לספק פתרונות בהם ישתמשו מתכנתי מערכת, כדי להרחיב ולשפר. אבל השאלה היא: מה יקרה במקרים מורכבים יותר, כגון: הודעה חוזרת, ודורשת עיבוד נוסף? כיצד מתכנני מערכת חסרי נסיון יתמודדו עם מקרים כאלה? הלקוחות מעוניינים בפתרון, שיגרום לתזרים העבודה להפוך נגיש לכולם. אך קודם עלינו לפתח תקנים סטנדרטיים, וזהו חלק בעייתי משום שאנו מתארים דבר שבסופו של דבר ירחיב את כל מודל התכנות. BPEL נולדה במאמץ משותף של BEA, Microsoft ואחרים כדי לפתור בעייה זו, כלומר – כיצד לפתח מודל סטנדרטי לכתיבת תזרים העבודה.
מבחינת המימוש, התכנית כאן ה- BEA היא להשתמש במידע נלווה כדי להרחיב את מודל התכנות הנוכחי – לתמיכה בתזרים העבודה, כך ששפת התכנות של הלקוחות תשאר Java. וזאת במידה רבה בגלל שאיננו חושבים שהלקוחות רוצים שפת תכנות נוספת, וכמובן שלא אחת המשתמשת בדקדוק של XML.
מה השונה בין זה ובין גישת ה- .NET? פילוסופיית ה- .NET כמדומני משמעותה "כל שפה, פלטפורמה אחת", כאשר גישת Java היא יותר "שפה אחת, כל פלטפורמה" ?
כאשר עבדתי במיקרוסופט, בניתי תשתיות מורכבות ללקוחות. הייתי די גאה בעבודה זו משום שהרגשתי שהצלחנו לספק את כל הכלים להם הלקוח זקוק. ב- Visual Basic סיפקנו את היכולת לבנות טפסים, ב- Active Server Pages את היכולת לבנות דפי אינטרנט, ב- XSLT את היכולת להמיר מ- XML ל- HTML, בשפת C את היכולת לכתוב קוד, ועוד.
אך כאשר הזדמן לי לפגוש לקוחות רבים, הוסבר לי שקשה מאוד להכשיר אנשים, ולכן עדיף להכשירם לשפה אחת. וכמעט בלי יוצא מן הכלל – כולם אמרו לי שבשל כך השפה המועדפת עליהם היא Java. מנקודת השקפתם, Java הגיעה לנקודה בה יש לה עוצמה מספקת עבור מתכנת מערכות ממוצע, ועם זאת הצליחה להסתיר את מורכבותה (דבר שגרם לשפת C להיות שפה ערמומית). איסוף אשפה, למשל, הוא דבר ש- Java עושה עבורך, כמו גם תורשה מרובה (multiple inheritance). שפת Java סיפקה פתרון מקיף ומקובל על כולם.
באותו זמן, לא הכרתי לקוחות רבים המשתמשים בפלטפורמה אחת בלבד. יהיה יהיר מצידי לומר שלא הרגשנו צורך לפתח מוצר בר שימוש בפלטפורמות רבות (Cross Platform). מאידך גיסא, ערכה של שפה רבת-פלטפורמות אינו ברור כל כך, ומתגלה כאשר כל המתכנתים שלך משתמשים בשפות וגישות שונות. אם Java הייתה שפה קשוחה או מוגבלת, היה הדבר טיעון טוב בעד המשך השימוש בשפות שונות. אך Java היא שפה קלה למדי. הקושי הרב בלימוד Java אינו לימוד השפה עצמה, אלא J2EE וכל התשתית הדרושה לבניית יישומי תקשורת הניתנים להרחבה בקלות. אם לומר את האמת – השקענו זמן רב בנסיון להפוך זאת לקל יותר.
לכן, הרעיון מאחורי ה-.NET בנוגע ליתרונן של שפות מרובות הוא דבר טוב, לדעתי, אך פתוח לדיון. זכור שהגעתי ממיקרוסופט ועדיין אני רוחש כבוד רב למהנדסים שתכננו את .NET, אך טרם שמעתי על בעייה של לקוח שנפתרה כתוצאה משימוש בשפות מרובות, ואכן שמעתי על בעיות שנוצרו כתוצאה משימוש בשפות מרובות. לכן תוכל לומר שאני מעט ספקן.
ובכן, נניח שאתה צודק בנושא זה. אך .NET הגיעה ממיקרוסופט, השולטת בנתח מכובד מן השוק. האם אין ביכולתם לשווק את .NETללקוחותיהם ביתר אגרסיביות?
כאשר מדובר במחשוב ארגוני, מיקרוסופט אינה השולטת השוק. מיקרוסופט למעשה יצרה לדעתי תהליך חיובי. מיקרוסופט גרמה לאנשי J2EE ב- Sun להתעורר ולפתח את יכולותיהם מהר יותר. עבור הלקוח – אלו חדשות טובות. בכל מקרה, הכל מסתכם בדרך בה אתה מטפל בשירותי הרשת, והאמת היא של- .NET ול- J2EE יש מקום לגדול בתחום זה.
בנוגע לשאלתך, עם כל האגרסיביות שמיקרוסופט מפעילה, הם עדיין מנסים, לא בהצלחה מרובה, להגיע אל עולם המחשוב הארגוני לאחר אחיזה חזקה בתחום המחשוב האישי. לעומת זאת, J2EE נמצאת בשימוש נרחב ע"י כמעט כל החברות ברשימת "Fortune 500", ומספק פתרון לכמעט כל היישומים החיוניים שתוכל להעלות בדעתך. אנו גם יודעים שארגונים משתמשים ב- J2EE על המחשבים המרכזיים הארגון, שעובדים על Linux או UNIX – הם בוודאי לא יוכלו להשתמש ב- .NET לשם כך. חשוב מה יקרה ל- .NET אם Linux תהפוך למערכת נפוצה מאד. ההסטוריה מראה לנו שישנו תמיד מנצח יחיד במלחמת התקנים בתוכנה. כרגע, למרות שברור ש- NT היא גורם חשוב במחשוב הארגוני, Linux לדעתי מתפתחת בקצה מהיר הרבה יותר. ואם הדבר ימשך – ו- J2EE תמשיך להוות שותפה טבעית ל- Linux – כנראה ש- .NET תהיה בצרות.
ציינת קודם את הכח הרב שיש לתקני תוכנה. שאלתי היא: מי יקבע את התקנים בתחום זה? האם נראה סטנדרטים הנקבעים ע"י ועדות כמו W3C ו- IETF? או שאתה צופה סטנדרטים שיקבעו הלכה למעשה ע"י השוק?
ב- BEA נקטנו בשתי גישות בנוגע לסטנדרטים. ראשית, ישנם את אלו המבקשים לממש קוד – לדוגמא, Java Community Process. עבדנו בצמוד אליהם כדי לפתור בעיות הקשורות לעולם התכנות שלנו. אך כאשר מדובר בנושאים הקשורים למעבר בין פלטפורמות, אנו נוטים לגלות יותר יצירתיות. וזוהי הנקודה בה אנו מגלים שישנן שתי חברות יישומים מרכזיות איתם חייבים לתקשר – אלו, כמובן, IBM ומיקרוסופט. אם אינך יכול לפעול יחד עם יישומים של IBM ויישומים של מיקרוסופט, איך תוכל להציע יכולת פעולה הדדית (אינטר-אופרביליות) ? ומצד שני – אם IBM, BEA ומיקרוסופט אכן יחברו יחד ויחליטו על דבר אחד – אזי מדובר במספר יישומים עצום, שהרי רוב יישומי הרשת מגיעים מאחת מחברות אלו.
אנו מציאותיים. זהו אך הגיוני לעבוד במשותף עם IBM ומיקרוסופט, כדי לפתח סטנדרטים שקרוב לוודאי יועילו לכל הלקוחות. כל שלושת החברות הללו חזקות מספיק כדי להאמין שלכל אחת מהן יהיה נתח גדול מספיק מן העוגה. אך קודם כל, חייבת להיות עוגה, ואנו מדברים פה על שילוב יישומים, דבר הדורש סטנדרטים. לכן, כדי להאיץ את היווצרות העוגה, אנו זקוקים לתקנים המקובלים ברמה עולמית.
כיצד אתה מעוניין להשפיע על סטנדרטים אלו?
אנו כרגע מבצעים עבודת חשיבה בנוגע לנושאים של חוסר סנכרון, ובפרט כיצד לגרום לשירותי הרשת הא-סנכרוניים לפעול היטב. אנו גם מנסים למצא דרכים לפתור את בעיות האמינות.
אך מהו הדבר הקרוב ביותר ללבכם? ברור כי מיקרוסופט תקדם את .NET ו- Sun תקדם את Java. מהו הדגל בו BEA מנופפת?
אנו מעין מודעת פרסום קטנה ל- J2EE. אנו היוצרים המקוריים של שרת יישומים מבוסס J2EE, אך עם זאת רחוקים מלהיות שרת היישומים הטוב ביותר. גם IBM מנופפת בדגל ה- J2EE, אך ההבדל ביננו הוא שאנו מתמקדים בחידושים שיעשו את העבודה קלה יותר. הם, באופן כללי, כ- 10 מליון איש כיום הכותבים קוד וכנראה שפחות ממליון מהם באמת עובדים בצורה יעילה ב- J2EE. אנו משנים זאת ע"י כך שאנו דואגים שכל מפתח יוכל לעבוד עם J2EE.
והאם J2EE חזקה מספיק כדי לעמוד בפני מגבלות סביבת הייצור?
אתה צוחק? יישומי J2EE חזקים בצורה יוצאת מן בכלל. כאשר מדובר בעמידות, זכור שרוב הלקוחות מריצים יישומים חיוניים. J2EE אינה הנושא פה. עבור הלקוחות, העניין העקרי הוא כיצד יישום מתפתח. אם אתה בונה ומריץ יישום שפועל 24 שעות ביום, 7 ימים בשבוע, 365 ימים בשנה, ברחבי העולם, אסור שהיישום יפסיק לתפקד. הבעייה מתעוררת כאשר תרצה להרחיב את היישום ולשנותו. זהו הנושא בו אנו מתמקדים כעת – היכולת לפתח ולשנות יישומים רצים בצורה קלה ומבוקרת, בלי הצורך בהפסקה והפעלה מחדש שלהם.
ואיך אתם מצליחים לעשות זאת?
אנו פועלים בשני מישורים שונים. השגנו התקדמות רצינית בנושא פיתוח קוד אינקרימנטלי (קוד המתווסף לקוד קיים), כך שאם אתה מבצע שינוי במחלקה יחידה, אינך זקוק להפיץ מחדש את כל היישום.
בנוסף, אנו משקיעים מאמץ רב במידע נלווה כך שכל מה שאנו יוצרים יהיה בר שינוי. בפרט, אנו עובדים על דרכים להפצת מידע נלווה בתוך הארגון, או בקבוצה של ארגונים. הרעיון הוא שהתנהגות היישום צריכה להשתנות בלי הצורך בהכנסת קוד חדש.
כשאני מסתכל על דברים כאלה, אני מניח שאתה זקוק לאשף תכנות ברמה 1, שיוכל לנהל ולהתמודד עם כל הפרטים. כיצד אתה מסתדר עם זה?
איני יכול לגלות לך את כל מה שאנו עושים, אך בוא נחשוב לרגע על המורשת של J2EE. מדוע ישנם מיכלים (containers) ב- J2EE? מפני שחשבו שזהו רעיון גרוע לתת למתכנתים לכתוב קוד ברמה תחתונה, קוד המחליט אם מדובר בפרוטוקולים חד כווניים (Stateless) או דו כווניים (Stateful) וכדומה. מודלים אלה הוסתרו במיכלים כמידע נלווה. אתה מתאר את הדרך להפצת היישום בעזרת "מתארי הפצה" (deployment-descriptors) ותיאור זה מספק למיכל את המידע הדרוש לו, כך שהמפתח אינו צריך לכתוב את כל הקוד.
במובן מסוים, J2EE החלה לפעול בתחום זה, כאשר היא מאפשרת לך לשנות את מתארי ההפצה ביישום פעיל, בידיעה ששינויים שמתווספים כעת יחלחלו לעומק היישום. ההתפתחות ההגיונית של גישה זו מבוססת על כך שקיים מידע נלווה המתאר את הדברים, ומידע זה יהיה ניתן לשינוי. החלק המתוחכם הוא כתיבת המיכלים – משימה קשה בפני עצמה. כלומר, קשה מאוד לכתוב את הקוד המנצל את המידע הנלווה, ופה אנו נכנסים לתמונה, ע"י כתיבת רכיבים המפשטים את הנושא. לך נשאר רק לנהל ולשנות את המידע הנלווה בלי לחשוב איך הדברים פועלים מבפנים. וכן- מה שאנו מפתחים הוא קשה מאוד לכתיבה, אך כאשר נעשה זאת כראוי – הדבר יחסוך לכולם את העבודה הכרוכה.
כעת נניח שהכל פועל בצורה טובה, ושירותי הרשת משגשגים ועונים על כל התחזיות. מהם הבעיות בהם נצטרך לטפל כחמש שנים מהיום?
אחת הבעיות איתה קרוב לוודאי נצטרך להתמודד היא מה שאני מכנה "איסוף אשפה ברחבי הרשת": קוד יוצר אובייקטים ובנקודה מסוימת הקוד מסיים את חייו, וכאשר זה קורה, אותם אובייקטים הופכים לחסרי שימוש – אשפה שיש לאסוף אותה. מפתחי שרת Apache שמו לב לעובדה זו, ולבעיות שנוצרו מכך, ולכן הם החליטו לסגור תהליכים בכל פרק זמן מסויים, כטכניקת מניעה. הסתבר שזו טכניקה מבריקה, וזו אחת הסיבות העיקריות ש- Apache משמש כמיכל רשת זמן רב כל כך.
לכן, אחת הטכנולוגיות שאנו מממשים היא יצירת תהליך שיגרום לכל המשאבים שנותרו "יתומים" (חסרי שימוש) להתחסל בצורה טובה. כאשר אנו עוברים למודל מבוסס מסרים, אנו מגלים ששירותי רשת מפעילים תהליכים שרצים זמן רב, וגורמים לעלויות מיותרות ברחבי האינטרנט. לפעמים יוצרי תהליכים אלה מסתיימים, ואין היום דרך נקייה ומסודרת להודיע זאת לכל התהליכים הצאצאים, כדי שיסתיימו אף הם. נכון להיום, אין לנו מושג כיצד זה יעבוד, והבעייה תתרחב כאשר יתווספו רשתות B2B ומכשירים ניידים. זהו אתגר אמיתי, לטפל בכל המידע הזה בזמן אמת. ושוב – מדובר במצב בו תהליכים עשויים לנסות להחזיר תשובה חזרה אל מערכת שאינה קיימת יותר. זוהי לא בעייה קלה.
ומה לגבי שפות תכנות?
ברור כי אתגר נוסף כרוך בשפה. כיום אין שפה המתמודדת בצורה טובה עם XML. ישנן יותר ויותר מערכות המשתמשות באופן אינטנסיבי ב- XML, אם בתור מידע נלווה המתאר את המשימה שיש לבצע, או כדרך להעביר מידע מיישום אחד לאחר. הצעד הראשון בכל אחת משפות אלה נקרא "כריכה" , ובו מתקיים עיבוד מידע ה- XML והפיכתו למבנה נתונים אותו שפות התכנות יכולות להבין. אם תשלח הזמנה למוצר ב- XML, הדבר הראשון שאצטרך לעשות הוא להפוך אותו לאובייקט מסוג "הזמנת מוצר". כאן ב- BEA השקענו רבות במציאת דרכים להתמודד עם זה ולדעתי עשינו עבודה די טובה. במצב אידאלי, לא תצטרך לבצע דבר מאלה. האידאל הוא שהשפה תבין את מסמך ה- XML ותוציא ממנו את המידע הדרוש, ואף יותר מכך – מכיון שמסרים אלה מתארים את עצמם, תוכל לתשאל את מבנה הנתונים, למשל, אם אדם רוצה לשלוח לך מסמך XML, תרצה בוודאי לתשאל אותו כדי לבדוק מהם הדברים שהוא מבקש. כיום איננו תומכים בכך, משום ששפות התכנות כיום אינן רגילות לחשוב על מבני הנתונים שלהם כאובייקט שניתן לתשאל אותו.
אני חושב ששינויים, שינבעו מצורך של שירותי הרשת, ידרשו הרחבות רציניות של שפות התכנות. וכתוצאה מכך נקבל שפה שמבינה את הרעיון של מידע המתאר את עצמו, ומסוגלת לתשאל את מידע זה, כמו ם להתייחס אליו כמבנה נתונים.
האם אתה מתכוון להרחבה של XML, או יצירה של שפה חדשה לגמרי?
שפות חדשות לגמרי מתפתחות לעיתים נדירות. מבחינתינו, נרצה כמובן לראות זאת כהרחבה ל- Java. ואנו רואים חלק מכך כבר קורה, ולו רק בגלל שחלק מלקוחותינו לא מעוניינים בשפה חדשה. הדבר מחזיר אותנו לעקרון בסיסי בתכנון, של אלן קיי. הוא אמר שדברים פשוטים אמורים להיות פשוטים, בעוד דברים קשים אמורים להיות אפשריים.
בעולם האמיתי של בניית יישומים, ישנם שלושה סוגי אנשים. ישנם את מתכנתי מערכת, שהם טובים בכתיבת קוד והפשטה, ויודעים בדיוק היכן הגבול בין השניים (כלומר, מה צריך להיות מתואר כמבנה נתונים ומה עדיף לטפל בו בצורה פרוצדורלית). ישנם את המפתחים עבור כלל השוק, המשתמשים בקוד לפתור כל בעייה ואינם משתמשים בהפשטה בדרך בה הם מתכננים דברים. אלה הם אנשים המבינים טוב לוגיקה פרוצדורלית ואינם טובים במיוחד בהפשטה לרמות גבוהות יותר. האחרונים הם אנשי העסקים ומשתמשים כללים, שאינם תכנתים אך באופן כללי די טובים גם בהפשטה וגם אם מדובר בדברים מורכבים. יש כאלה שישתמשו ב- Access או Visio כדי לבנות דיאגרמות מורכבות מאוד, או בסיסי נתונים מורכבים מאוד. בכל מקרה תרצה שכל אלה יוכלו לעבוד יחד. לכן שיניתי את אמרתו של אלן קיי ל: "על דברים פשוטים ניתן להצהיר, בדברים מסובכים ניתן לטפל בצורה פרוצדורלית".
במונחים של איך אנו מתכוונים לספק את כל אלה, אנו צופים שותפות טבעית בין משתמשים חזקים ותכנתים. מטרתינו היא לאפשר לתכנתים בארגון לתקשר בעזרת XML ומידע נלווה. ולדעתי, כל השפות מתפתחות באופן שיאפשר טיפול טבעי יותר בנושאים אלו.
האם ישנם שינויים אחרים שאתה צופה לטווח הרחוק?
השינוי הגדול ביותר שאני צופה הוא התרחקות מעולם המידע לכוון עולם המסרים. בשנות ה- 90' היינו עדים לנצחון מחשוב השרת/לקוח. ראינו שינויים תכנותיים רבים שהובילו לתקשורת קלה יותר מול בסיסי נתונים. רוב אלה היו יישומים המבוססים על נתונים – קלאסי למודל דו-דרגתי. אך כעת אנו עוברים למודל N-דרגתי. במודל זה, הבעיות האמיתיות קשורות לחשיפת פרטים רבים למערכות אחרות, מחוץ לחוג הקרוב אליך.
במשך 10 השנים הבאות, אנו נעבור לתקשורת מונחית מסרים, עם מערכות שיתקשרו ביניהן דרך ערוצים ציבוריים בצורה א-סינכרונית. לאחר מכן, שינויים רבים שנראה יהיו קשורים לאופטימיזצייה של מודל תקשורת זה. אפילו כיום ישנם לקוחות המבקשים לשלוח מעל ל- 500,000 מסרים בשנייה.
אנו נהיה חייבים לשפר את הדרך בה מסרים זורמים. איננו יכול לעשות זאת כרגע. תוכל לשלוח מסרים בקצב של 500,000 לשנייה, רק אם תהיה לרשותך יכולת שידור מדוייקת. אך לקוחותינו מבקשים מאיתנו לכתוב מודלים מבוססי מסרים המתמודדים עם צורת שליחת המסרים, דרך השליטה בהם ודברים דומים נוספים. והם רוצים שאת כל אלה ניתן יהיה להרחיב. הדבר נשמע מעט מפחיד, אך למעשה אינו רע כמו שהוא נשמע. אחרי הכל, באמצע שנות ה- 80', כשהתברר שמסדי הנתונים היחסיים הם הדרך הנכונה לפעול, בסיס הנתונים Oracle היה "כלי מזערי" במונחים של ביצועים. אך ככל שיותר לקוחות עברו לעבוד בצורה זו, Oracle ואחרים הצליחו לספק את הביצועים להם נדרשו. וישנם דוגמאות רבות אחרות לכך.
ההסטוריה מראה שאם תסתכל חמש שנים קדימה, מן הנקודה בה הטכנולוגיה החלה, בדרך כלל תגלה שהתבצעה פחות התקדמות מכפי שציפו. אך אם תתבונן בגרף ההתקדמות מאוחר יותר, תגלה שהגעת בדיוק לנקודת השינוי, כך שלמעשה במהלך עשר שנים, חלה התקדמות רבה יותר מן המצופה. לדוגמא, כולנו התחלנו בפיתוח מיחשוב השרת/לקוח בסביבות 1990, אז התחלנו לבנות תשתיות ושאר חלקים נחוצים. אך רק בסביבות 1995 דברים החלו להמריא. באופן דומה, בשנתיים האחרונות שירותי הרשת התקדמו באיטיות מכפי שציפו. לא הגענו לשלב ההטמעה אותו צפינו, אך קח בחשבון שהכל רק פורסם באותה תקופה. רק אם תתבונן לאורך תקופה של עשר שנים, תוכל לראות את צידה האחר של עקומת ההתקדמות. באופן וודאי, תהיה נקודה בה תראה התקדמות בקצב מסחרר.
ובחזרה לדוגמת בסיס הנתונים. Oracle הימרה על הסטנדרט העתידי, וכוחו של סטנדרט זה הביא אותם למיצובם כיום. לחברות אחרות לא שחק המזל, ואני צופה שנראה זאת גם בתחום שירותי הרשת. ישנן כיום חברות המהמרות על סטנדרטים פרטיים למסרים ושילובי יישומים – חלקם די חזקים. אך אם תסתכל על דברים 10 שנים מהיום, תגלה שהנוף השתנה באופן דרמטי למדי.
הערות שוליים – תוספות המתרגם, דורון מירז
- Stateless protocols – המינוח "Stateless" מתייחס לפרוטוקולים חד-כיווניים, שאינם ממתינים לתגובת הצד השני (למשל – לאחר שליחת מידע, אין המתנה לקבלת אישור שאכן המידע נתקבל). מעין "שלח ושכח". דוגמאות לפרוטוקולים כאלה: HTTP, UDP. בניגוד לפרוטוקולים מסוג "Stateful", הממתינים לאישור קבלת המידע מן הצד השני (כמו TCP).
- מנשק – נצלתי את ההזדמנות לתקן טעות נפוצה בתרגום: תרגום המילה Interface הוא "מִנְשַק" ולא מִמְשַק. (מן השורש נ.ש.ק.).
- Message Brokering- המונח "Brokering" משמעותו הפחתת העומס על הרשת ע"י איסוף כל המידע מהלקוח המיועד לכתובת מסויימת, או איסוף כל המידע המיועד לעיבוד מסויים, לפני שליחתו.
- Meta-Data – מידע "נלווה" – כאשר נשלח מידע דרך הרשת, בנוסף למידע עצמו ששולח המשתמש נשלחים איתו "תוספות" שהוא אינו מודע להם אך הם חיוניים לפעילות המערכת. תוספות אלה יכולות לתאר למשל – מאיזה מחשב נשלחה הבקשה, באיזה זמן נשלחה, מהי תוכן הבקשה ומהם הרשאות המשתמש.
- (Business Process Execution Language) BPEL – שפה לבצוע עסקאות – שפה מבוססת XML המאפשרת שיתוף משימות עבור מערכות מחשוב מבוזרות (אפילו אם מדובר במערכות בין ארגונים), בעזרת צירוף של מספר שירותי רשת. השפה פותחה ע"י חברת BEA Systems, IBM, ו- Microsoft.
Credits
ACM Queue, Vol. 1, No. 1, March 2003, Pages 12–21.
Copyright 2003 Association for Computing Machinery, Inc. Translated with permission.
