שירות רשת (באנגלית: Web Service) נקרא גם: Web-API, היא דרך להתחבר לתוכנה, לקבל שירותים ממנה ולהשתמש בהם. כך למשל, כאשר מתכנת מעוניין להשתמש בשירותי מפות של חברה המספקת שירותי מפות כמו Google או Apple, המתכנת מתחבר לשירותי ה-Web Service שלהם ובכך מוסיף לתוכנה שהוא מפתח את היכולות שיש כבר לשירותי המפות, במקום לפתח בעצמו שירות מפות.
בעבר נבנו שירותים כאלו רק לפי אוסף תקנים מורכב, הכולל למשל את תקן SOAP, אך בהמשך הופיעו חלופות פשוטות יותר שלא ענו לתקן רשמי, כדוגמת שירותי רשת מבוססי REST.
הגדרה
שירותי רשת מתבססים על תקנים המהווים מכנה משותף לסביבות תוכנה שונות ברשת, כגון HTTP. הגדרה של כל תקן כזה היא באמצעות תפקיד, פונקציונליות, מבנה המסרים ותוכניהם, במטרה לשלב בקלות יחסית רכיבי תוכנה מסביבות תוכנה שונות.
אין הגדרה אחת מקובלת של Web Services. חלק מההגדרות מציינות את השימוש בטכנולוגיות סטנדרטיות וחלק מההגדרות מתייחסות להיבט של אינטגרציה. להלן מספר הגדרות:
רכיב תוכנה המתואר באמצעות WSDL וניתן לגשת אליו באמצעות פרוטוקולי רשת תקניים כמו SOAP ו-HTTP אבל לא בהכרח באמצעות פרוטוקולים מסוימים אלה - הגדרה של OASIS.
הגדרות המציינות הכרח בשימוש בשלושת התקנים העיקריים של WSDL ,UDDI ,SOAP :Web Services או חלק מהם.
Web service הוא מערכת תוכנה שתוכננה לתמוך באינטראקציה משולבת של מכונה-מכונה ברשת. יש לו ממשק בפורמט ספציפי הנקרא WSDL הניתן לעיבוד על ידי מחשב. האינטראקציה של מערכות אחרות עם Web service היא באמצעות מסרי SOAP, כשבדרך כלל משתמשים ב-HTTP בשילוב עם XML serialization - הגדרה של W3C[1].
מבוא
איור 1: Web Service
התחלת השימוש במושג Web Services הייתה בשנת 1999, עם הצגת מהדורה ראשונה של SOAP. התפיסה הפכה למקובלת בעשור הראשון של המאה ה-21. אופן פעולת שירותי הרשת מתואר באיור 1.
ניתן לראות מהאיור כי קיים ממשק מצד ספק השירות וממשק מצד צרכן השירות. היות שהאינטראקציה היא ביניהם ולא בין השירות לצרכן ישירות, מופחתת באופן משמעותי התלות בטכנולוגיית השירות עצמו. משמעות מעשית של הקטנת תלות זו היא היכולת להחליף באופן שקוף למשתמש את השירות בשירות זהה פונקציונלית המתבצע בסביבה טכנולוגית אחרת. החלפה כזו עשויה להידרש למשל במקרים של שימוש בטכנולוגיות ישנות שאינן נתמכות על ידי היצרן או בטכנולוגיות ששכיחות השימוש בהן נמוכה ולכן קיים קושי למצוא אנשי מקצוע שיתחזקו את התוכנה. מהאיור ניתן ללמוד כי לא בהכרח הקשר בין ממשק השירות לממשק הצרכן הוא קשר ישיר: המסר המורכב ממסמך XML תקני עשוי לעבור דרך שרתים מתווכים שעל פי תכנים במעטפת המסר ידעו מי השירות המהווה יעד למסר.
ניתן לתאר את התקנים באמצעות מחסנית בת שלוש שכבות הקרויה Web Services Stack ומתוארת באיור 2.
איור 2: Web Services Stack
השכבה התשתיתית ביותר היא שכבת ה-Wire Stack תקנים השייכים אליה משמשים להעברת מסרים. התקן הבולט ביותר בשכבה זו הוא SOAP.
מעליה נמצאת שכבה הנקראת Description Stack. תקנים כגון WSDL ו-WS-BPEL השייכים אליה מתארים את השירות.
תקן בולט בשכבת ה-Discovery הוא UDDI. שכבה זו עוסקת באיתור שירות מתאים באופן דינמי. כך למשל בחיפוש שירות המספק פונקציונליות של שכירת רכב ניתן לקבל רשימה של שירותים המספקים פונקציונליות זו. לא תמיד ניתן לשייך פונקציונליות של תקן של Web Services לשכבה אחת ספציפית. בהחלט ייתכן שחלק מהפונקציונליות של תקן מסוים תשתייך לשכבה מסוימת וחלק אחר שלה לשכבה אחרת.
בנוסף לתקנים הניתנים למיפוי, קיימים תקנים המטפלים בכל שכבות המחסנית. באיור 2 הם מתוארים בחלק האדום של האיור. תקנים בולטים המתייחסים לכל שכבות המחסנית הם אלה של אבטחת מידע והתקנים המטפלים בטרנזקציות.
בפיתוח Web Services מתווסף שלב של פרסום (Publishing), שבדרך כלל אינו חלק מתהליך של פיתוח יישום בסביבה שאינה סביבת Web. הפרסום הוא הצגת הפונקציונליות של השירות ואופן ההתקשרות אליו ופרטים מזהים על יצרן השירות בקטלוג המתאר שירותים. להלן תיאור סכמתי פשוט של מימוש פניה של צרכן ל-Web Service על בסיס שלושת התקנים הבסיסיים:
הצרכן מעביר מסר המבקש שירות בעל פונקציונליות מסוימת ההעברה היא באמצעות שימוש ב-SOAP על פרוטוקול HTTP או פרוטוקול אחר של TCP/IP.
מתבצע איתור של שירות מתאים ב-Registry אחד או יותר הממומשים באמצעות תקן UDDI.
להפעלת השירות נעשה חיבור (Binding) בין בקשת הצרכן לבין דרישות השירות תוך שימוש בתקן WSDL.
Organization for the Advancement of Structured Information Standards ובראשי תיבות OASIS.
תהליך הגדרת תקן חדש מתחיל בהצעת טיוטה (draft) של חבר או חברים בארגון התקינה. אם היא מתקבלת ממונה ועדה שמטפלת בקידום הגדרת התקנים החדש. תקנים קיימים מורחבים במהדורות חדשות על פי היזון חוזר מהשטח. חבר בארגון התקינה עשוי להיות אדם פרטי או חברה. באופן מעשי מציעי הטיוטות הם בדרך כלל נציגי חברות. לפני הצעת הטיוטה מתאגדות מספר חברות ודנות ביניהן על הטיוטה ואז מציעות אותה במשותף. היות שלחברות פתרונות קנייניים, בדרך כלל מבוססת הטיוטה על הטכנולוגיות הקנייניות של החברות המציעות. לכל חברה יש אינטרס מסחרי, שהתקן יהיה דומה ככל שניתן לפתרון הטכנולוגי הקנייני שלה, וכתוצאה מכך בהחלטות ביחס לתקנים יש מרכיב פוליטי. כפי שצוין לעיל יש שני ארגוני תקינה, כך שההחלטה לאיזה ארגון להפנות את הטיוטה, עשויה אף היא לכלול מרכיבים פוליטיים. באופן מעשי שתי החברות הדומיננטיות בקביעת התקנים הן מיקרוסופט ויבמ, כך שהיוזמה לתקנים שמתקבלים על ידי ארגוני התקינה היא במקרים רבים של שתי חברות אלה בצירוף לפחות חברה נוספת, שמיוצבת היטב בתחום אליו מתייחסת הטיוטה. כך למשל בתקן של
WS-Reliable-Messaging צורפו לטיוטה חברת Tibco וחברת BEA ולטיוטת תקן UDDI צורפה חברת Ariba. בין התוצאות של השפעת שיקולים עסקיים של חברות על תקנים ניתן למנות:
תקנים מתחרים עם חפיפה פונקציונלית ביניהם. למשל: WS-BPEL ו WS-Choreography ו WS-Reliable-Messaging ו WS-Reliability שהוגשו כטיוטות על ידי קבוצות חברות שונות.
אין קשר ברור בין עולם התוכן של התקן וארגון התקינה המטפל בו. כך למשל קיימים מספר רב של תקנים של אבטחת מידע עבור Web Services המחולקים בין שני ארגוני התקינה ללא תיחום פונקציונלי ברור.
לא בהכרח קיימת תאימות בין יצרנים שונים במימוש פתרון לתקן גם אם יצרנים שונים תומכים בתקן.
על מנת להתמודד עם חוסר התאימות בין יצרנים והחשש להתפצלות היוזמות הקשורות לתקנים של שירותי רשת הוקם ארגון נוסף ששמו
-WS-I (Web Services Interoperability Organization) ארגון זה אינו מייצר תקנים, אלא מתמקד בהבטחת עבודה משותפת (Interoprability) בין מימושי Web-Services של יצרנים שונים בשטח. לצורך כך הוא מעניק מעין תו תקן ליצרנים.
WS-I הוא ארגון המאגד את מרבית היצרנים המובילים, במטרה לאפשר Interoperability אמיתי במציאות בין סביבות טכנולוגיות שונות בהקשר של Web Services. קיומו של ארגון כזה מעיד על כך שאין די בתקנים על מנת ליצור Interoperability. התוצר המרכזי של פעילות WS-I הוא WS-I Basic Profile. בתוצר זה כמו גם בתוצרים אחרים מוגדרות דרישות מעשיות לתאימות. התוצר מספק הנחיות למימוש ומתייחס לאוסף מצומצם של תקנים, כשלגבי כל אחד מהם מוגדרת מהדורה ספציפית.
תקנים
מספר התקנים של Web Services הוא גדול. יש כ-50 תקנים שונים אליהם מתווספים תקנים חדשים. בתעשייה נהוג להתייחס לאוסף תקנים אלו בשם WS-*. שכיחות שימוש גבוהה קיימת רק בחלק קטן מהתקנים. בחלק זה של הערך יוצגו בקצרה מספר תקנים, חלקם בשלים יחסית וחלקם בעלי חשיבות מבחינת הפונקציונליות המוכלת בהם.
SOAP: בעבר המונח SOAP היה ראשי תיבות של Simple Object Access Protocol. החל ממהדורה 2.0 האותיות אינן מייצגות ראשי תיבות, אלא יש רק צירוף בן 4 אותיות. יוזמי תקן זה עבדו בחברת מיקרוסופט ובחברות הקשורות אליה: Developmentor ו-Userland. זהו פרוטוקול להעברת ההודעה בין שני צדי ההתקשרות. הפרוטוקול בנוי ממעטפה הכוללת מידע על המסר ובתוכה את תוכן המסר. התקן SOAP הוא RPC מבוסס XML. תקן זה הוא תקן של W3C.
WSDL (Web Service Description Language): שפה המאפשרת לתאר את הממשק של ה-Web service, טיפוסי הנתונים ה-XML-ים שהוא מקבל ופרטים הקשורים לפרוטוקולי התקשורת שהוא תומך בהם. תקן זה הוא תקן של W3C. בפיתוח Web services קיימות שתי גישות לעבודה עם WSDL. גישה ראשונה גורסת שיש לכתוב את ה-WSDL ואז לכתוב את הקוד של ה-Web service כך שיממש את הממשק שהוצהר בו (לרוב ייעשה שימוש בכלי תוכנה אוטומטיים על מנת לייצר stub-ים עבור שפת המימוש המבוקשת). גישה אחרת טוענת שיש לכתוב את המימוש האפליקטיבי של ה-Web Service, ולהשתמש בכלים אוטומטיים כדי לייצר את ה-WSDL.
UDDI (Universal Description, Discovery and Integration): פרוטוקול המאפשר לפרסם ולצרוך מידע אודות שירותים. באמצעות פרוטוקול זה יישומים יכולים לאתר שירותים ולצרוך אותם בזמן עיצוב וגם בזמן ריצה. ספקי Web services יכולים לפרסם את ה-Web services שלהם ב- UDDI Registry שהוא מסד נתונים דמוי "דפי זהב" ומכיל מידע על Web Services. הרעיון של UDDI Registry אוניברסלי לאינטרנט כלו, שהווה בסיס למהדורה הראשונה של התקן נכשל ומהדורה 3 מציגה תפיסה המאפשרת שילוב בין UDDI Registries. תקן זה גובש על ידי ארגון תקינה פרטי בשם UDDI.ORG והועבר ל OASIS.
WS-BPEL (Web Service Business Process Execution Language): תקן למימוש תהליכים עסקיים מבוססי Web Services באמצעות Orchetration של Web Services. התקן בנוי על שתי שפות קנייניות לביצוע תהליכים: שפה של חברת מיקרוסופט ושפה של חברת IBM. זהו תקן בטיפול ארגון התקינה OASIS.
WSDM (Web Service Distributed Management): תקן המשמש לניהול Web Services. ארגון התקינה האחראי עליו הוא OASIS. תקן זה הוא רוחבי ואינו שייך לשכבה מסוימת של ה Web Services Stack.
WS-Security: תקן שמתאר כיצד נתן לאבטח את הודעות SOAP באמצעות יכולות של הצפנה, חתימה דיגיטלית, שם וססמה וכן Timestamp. השימוש ב WS-Security הוא אלטרנטיבה לאבטחת התקשורת באמצעות HTTPS. התקן מתייחס לשכבת ה Wire ב Web Services Stack. תקן זה הוא חלק מאוסף תקנים בנושא אבטחת מידע ועוסקים בהצפנה, חתימה דיגיטלית, מדיניות אבטחת מידע, Provisioning ועוד שכולם מבוססי XML. חלקם תקנים של OASIS וחלקם תקנים של W3C.
WS-Policy: אחד מהתקנים הקשורים לאבטחת מידע. מאפשר ל Web Services להציג את המדיניות שלהם בנושאים כמו אבטחה ואיכות שירות באמצעות XML. מתמקד בעיקר בשכבת ה-Description של ה Web Services Stack. תקן של W3C.
WS-Federation: אחד מהתקנים הקשורים לאבטחת מידע. מאפשר ניהול זהויות בין מערכות שונות של Authentication ו Authorization. יוזמות התקן IBM ומיקרוסופט בצירוף RSABEA ו-VeriSign. מטופל על ידי OASIS.
WS-Transactions: אסופת תקנים שמתארים כיצד נתן לנהל קריאות ל Web Services בצורה טראנזקציונית. קיימים מספר תקנים בתחום זה: BTP (Business Transaction Protocol) שהוא תקן ישן יחסית שמתאר כיצד נתן לנהל תקשורת XML-ית כלשהי בצורה טראנזקציונית, ולאו דווקא תקשורת מבוססת Web Services, ואסופת התקנים WS-TX מוכוונת ה Web Services שכוללת את התקנים: WS-Coordination, WS-AtomicTransaction ו - WS-BusinessActivity. הטיפול בטרנזקציות הוא רוחבי ואינו מתייחס לשכבה מסוימת במחסנית התקנים.
WS-Addressing: באופן נורמלי, ללא שימוש בתקן WS-Addressing, הודעות SOAP יישלחו ל Entry Point שצוינה עבור השירות, ותוצאת העיבוד תשלח חזרה לגורם שייצר את הבקשה. תקן WS-Addressing מאפשר להרחיב את המודל הזה ולציין אינפורמציית ניתוב בגוף הודעת ה SOAP. פרטים שיכולים להכלל במשלוח: כתובת הגורם אליו תשלח תוצאת העיבוד וכתובת למשלוח שגיאות. תקן זה מנוהל על ידי W3C. נכלל בשכבת ה Wire.
WS-Eventing: מנוי של Web Services לאירועים שנוצרו על ידי Web Services אחרים. המנוי הוא באמצעות Publish&Subscribe. זהו תקן של W3C.
WS-Notification: תקן של OASIS. מתחרה ב WS-Eventing . יוזמות התקן AmberPoint, CA, Fujitsu, HP, Hitachi, IBM, Oracle, SAP, Sonic Software, Tibco Software ו-WebMethods (האחרונה היא היום חלק מחברת Software AG שרכשה אותה).
תקנים בהעברת מידע בינארי
כיוון שלא הוגדרו תקני העברת מידע בינארי מראשית השימוש ב-SOAP, התקבעו מספר פורמטים ולאחר מכן תוקננו.
SwA הייתה הצעה של תקן להעברת הודעות אשר הוחלפה על ידי DIME ו-XOP.
DIME (Direct Internet Message Encapsulation) הוא תקן שהוצע על ידי מייקרוספט החל משנת 2000 והוחלף על ידי XOP לאחר מכן. הוא מגדיר כיצד לבצע הכלה של מידע בינארי בתוך הודעת אחרות. DIME הוסיף הודעות לפני ואחרי הודעת ה-SOAP (המידע שנוצר אינו במבנה XML), אשר קבעו את אופן הצגת ההודעה, תוכנה ומאפייניה. ניתן לראות שימוש רב בתקן זה בפלטפורמת .NET עד לגרסה 3.5. הבעיה הגדולה של תקינה זו היא חובת הידיעה של כל המידע אשר ישלח בזמן יצירת ההודעה, והתאמת ה-Parser לעבודה עם DIME[2].
XOP פורמט שמומש בעיקר במערכות משובצות ומערכות שעברו לעבוד לפי התקינה החדשה של W3C.
ביקורת על Web Services
למרות היתרונות של התקניוּת וקלות הפיתוח של Web Services יש להם גם חסרונות שהעיקרים בהם מצוינים להלן:
ביצועים - הטכנולוגיה התקנית המשמשת את Web Services עשויה במקרים רבים להיות פחות יעילה מטכנולוגיות קנייניות ולפעמים אינה עונה על רמת השירות הנדרשת בארגון. מקורות בולטים לחוסר היעילות הם השימוש ב XML המחייב Serialization ו Deserialization וכמות הנתונים הגבוהה במיוחד המועברת ברשת ובגלל רמת הביצועים הנמוכה של פרוטוקול התקשורת HTTP.
חוסר בשלות - תהליך ההבשלה של תקנים הוא ארוך. מרבית התקנים עדיין אינם בשלים מספיק. כך למשל התקן WS-Atomic-Transaction עוסק בתחום חשוב אך אינו בשל דיו (הוא גם סותר תקנים אחרים בתחום שאינם קשורים ל Web Services)
מגבלות באבטחת מידע - התקן מבוסס על העברת המסרים דרך מחשבי ביניים (למשל: Proxy) היות שהתקן מבוסס על תוכני המסרים עשויה להידרש פתיחת המסרים בתחנות ביניים.
אי-הסכמה על המבנה הארכיטקטוני של מחסנית התקנים: גוף אחד עשוי למקם תקן בשכבה מסוימת של המחסנית בעוד גוף אחר עשוי למקמה בשכבה אחרת.
תקנים תשתיתיים שאינם תומכים בהיבטים סמנטיים עסקיים. יוצא מן הכלל התקן הלא פופולרי EBXML שנותן מענה להיבטים מסוג זה, אך אינו זוכה להצלחה משום שחברת מיקרוסופט אינה תומכת בו.
התקנים מושפעים באופן רב משיקולים פוליטיים של יצרני תוכנה.
Web Services וסביבות פיתוח וריצה
מרבית סביבות הפיתוח יודעות לחולל באופן אוטומטי Web Services, על בסיס הגדרות פרמטריות של התוכניתן. בסביבת .NET של מיקרוסופט, שפותחה מאוחר יחסית, Web Services הם חלק אינטגרלי מסביבת הפיתוח הכוללת. סביבת J2EE הוותיקה יותר הורחבה לתמיכה ב-Web Services באמצעות שימוש ב-API. בין ה-APIs אפשר לציין JAX-RPC ואת JAX-WS המאוחר יותר. גם בסביבות אחרות כגון CICS במחשבים מרכזיים (Mainframe) התווספה תמיכה.
בשפות אחרות יש צורך בכתיבה ידנית של אוסף הפעולות שיבצעו את סרליזציית המידע וינהלו את העברת ההודעות. לשם כך ניתן להשתמש למשל בשפת C וב-JAVA בספריות (frameworks) המאפשרות יצירת קוד stub לפי הגדרת WSDL, או יצירת WSDL מקובץ הגדרות. דוגמאות לספריות כאלו:
מספר מערכות שמייצרות קוד (code generation) מקשות במיוחד שימוש בתקני W3C חדשים בנושאי SOAP:
נושא ה complexTypes במערכות .NET ישנות מקשה על מתכנת לא מנוסה ליצור תמיכה בעבודה ב rpc/literal ו document/literal ולמעשה מאפשר עבודה רק ב rpc/literal. (הבעיה לא קיימת בשימוש ב C, Java, פרל וכו').
שימוש במבני נתונים מתקדמים (לדוגמה מערכים ורשימות מקושרות כמעט ולא נפוץ במערכות . NET כלפי מערכות אחרות -
על פי הנהוג ב Java ושפות אחרות מתבצע המרת הנתונים לsequence sequence אשר לא קיים עבורו הגבלה של כמות מופעים (unbounded) מסוג xsd:anyType . למעשה מערכות web services מדברות בין פרל ל Java ול-C (בשימוש בתשתיות תוכנה דוגמת gSOAP ו Axis) אולם יש לבצע התאמת קוד שנוצר ב .NET (בין אם זה C++/C או C#) לשם ביצוע העברת מידע בין סביבת .NET לאחרות.
Considering how much have already been accomplished in in the area of Web Services, some wondering if official standards are necessary but they are and standardization is well underway/ Anne Thomas Manes, Systinet
