הרשמה לניוזלטר

    כל השדות הם חובה למילוי

    "להתיר את הקורים" – הכרות עם WSDL ,SOAP ו- UDDI

    מבוא

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

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

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

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

    • פרוטוקול פשוט לגישה לאובייקטים (Simple Object Access Protocol – SOAP)
      http://www.w3.org/2002/ws
      המאפשר תקשורת בין שירותי רשת.
    • שפת תיאור שירותי רשת (WSDL – Web Services Description Language)
      http://www.w3.org/TR/wsdl.html
    • המספקת תיאור רשמי, באופן קריא ע"י מחשב, של שירות רשת.
    • המדריך לתיאור, גילוי ומיזוג אוניברסלי (UDDI – the Universal Description, Discovery, and Integration directory)
      http://www.uddi.org
      שהינו בעצם רשם של תיאורי שירותי הרשת.

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

    תקשורת – SOAP

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

    לאחרונה הופיע SOAP, שבמקור פותח ע"י Microsoft ובהמשך פותח בשיתוף חברות כמו Developmentor, IBM, Lotus, ו- UserLand. SOAP הוא פרוטוקול מבוסס XML, המיועד למסרים והפעלת תהליכים מרחוק (RPCs). במקום להגדיר פרוטוקול העברה (Transport) חדש, SOAP עובד על פרוטוקולים קיימים, כגון HTTP, SMTP ו- MQSeries.

    בבסיסה, להודעת SOAP מבנה פשוט מאוד: אלמנט XML ולו 2 אלמנטים בנים, האחד מכיל את הכותרת והשני את גוף ההודעה. שניהם, הכותרת וגוף ההודעה, הם אלמנטי XML בעצמם.

    בתרשים (1) ניתן לראות מבנה מעטפת SOAP. המעטפה מכילה אלמנטי בנים, בהם נמצא כותרת ההודעה וגוף ההודעה.

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

    העברת הודעות באמצעות SOAP

    מבחינת תפקוד בסיסי, ניתן להשתמש ב- SOAP כפרוטוקול פשוט להחלפת הודעות. במהלך מאמר זה נדגים את מפרטי שירותי הרשת בעזרת דוגמא פשוטה הלקוחה מעולם שירותי הנסיעות. למטייל שלנו, ג'ו, נקבעה טיסה אחה"צ וברצונו לבצע את הליך ההרשמה (Check In) בצורה אלקטרונית. נניח שג'ו יודע על שירות המספק דרך לבצע הליך הרשמה אלקטרוני, ומכיר את התבנית על פיה בנוי הכרטיס. מכאן – ג'ו יוכל ליצור ולשלוח הודעת SOAP אל אותו שירות.

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

    תרשים (2) מציג הודעת SOAP שכזו, הנישאת מעל פרוטוקול HTTP. כותרות ה- HTTP נמצאים מעל הרכיב SOAP:Envelope. הכותרת POST מציינת שההודעה נשלחת בעזרת HTTP POST, שיטה הנמצאת בשימוש ע"י דפדפנים לשליחת טפסים. אחרי כותרת ה- POST ישנה הכותרת (לא הכרחי) SOAPAction, המציינת את ייעוד ההודעה. אם להודעה היתה תגובה, אזי תגובת ה- HTTP תהא מסוג text/xml, בהתאם לכתוב בכותרת ה- Content Type, והתגובה תוכל להכיל בתוכה הודעת SOAP עם תשובה מתאימה. לחילופין, יוכל הנמען להחזיר תשובה מאוחר יותר (באופן אסינכרוני).

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

    קריאה לפרוצדורות מרחוק (RPCs) ע"י SOAP

    כדי להשתמש ב- SOAP לקריאה לפרוצדורות, עליך תחילה להגדיר פרוטוקול קריאה לפרוצדורות מרחוק, הכולל:

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

    מפרט ה- Schema של (http://www.w3.org/XML/Schema) W3C מספק שפה סטנדרטית להגדרת מבנה מסמך, וסוגי נתוני ה- XML. כלומר, בהנתן טיפוס נתונים פשוט כמו מספר שלם, או מורכב יותר – כמו רשומה עם שני שדות (לדוגמא – מספר שלם ומחרוזת), XML Schema מציעה דרך אחידה לייצג טיפוס נתונים זה ב- XML. בכדי לאפשר שידור של הערכים שהוכנסו, SOAP מניחה שנעשה שימוש במערכת ייצוג טיפוסי נתונים מבוססת XML Schema, ומגדירה את הכללים בעזרת XML. בעזרת שימוש בצורת קידוד זו, תוכל לקודד לתבנית XML כל סוג של נתונים מבניים. ארגומנטים עבור קריאה לפרוצדורה מיוצגים אף הם בדרך זו.

    כעת, נניח שג'ו מעוניין לדעת אם חל עיכוב בטיסתו. הוא יודע שהשירות מספק פונקציה, הנקראת GetFlightInfo, המקבלת שני ארגומנטים – מחרוזת, המכילה את שם חברת הנסיעות, ומספר שלם – מספר הטיסה; ומחזירה רשומה עם שני שדות: מספר השער ומצב הטיסה. אם כך, ג'ו יכול לדעת את מצב הטיסה ע"י שליחה אל השירות, בעזרת HTTP POST, שישא מעטפת SOAP הדומה לזו המתוארת בתרשים (3).

    במעטפת SOAP זו, הקריאה ל- GetFlightInfo היא אלמנט XML עם תכונות הכוללות מידע על הקידוד (שים לב למראי המקום אל XML Schema). צאצאי האלמנט הינם הארגומנטים של הפרוצדורה: airlineName ו- flightNumber. טיפוסים אלה מוגדרים בתכונות הטיפוס, באשר xsd מתייחס אל הגדרות סכמת ה- (XML Schema) XML. כאשר יישום ה- SOAP מקבל את ההודעה, הוא ממיר את טקסט ה- XML למחרוזת UL ולמספר 506. לאחר מכן, הוא קורא לפרוצדורה GetFlightInfo עם ארגומנטים אלה.

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

    יישומי SOAP קיימות עבור מספר שפות תכנות, ביניהם C, Java ו- Perl, אשר מייצרים ומעבדים באופן אוטומטי הודעות SOAP. בהנחה שההודעות תואמות את מפרטי SOAP, אלה יכולות להחליף מידע בין שירותים המיושמים בשפות תכנות שונות.

    תיאור – WSDL

    לדבר בשפה אחידה אינו מספיק, אלא אם אתה מסוגל לנהל שיחות בסיסיות המאפשרות לך להשיג את מבוקשך. עבור שירותי רשת, SOAP מאפשרת תקשורת בסיסית, אך אינה מפרטת אילו הודעות אנו חייבים לשלוח בכדי לתקשר בצורה טובה עם שירות מסוים. לתפקיד זה נועד WSDL, תבנית XML שפותחה ע"י IBM ו- Microsoft לתיאור שירותי רשת כאוסף של נקודות קצה בתקשורת, היכולות להחליף ביניהם הודעות מסוימות. במילים אחרות – מסמך WSDL מתאר את ממשק שירות הרשת ומספק למשתמשים בו דרך התקשרות.

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

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

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

    תאור מופשט

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

    תרשים (5) מציג שני טיפוסי נתונים המוגדרים בעזרת XSD (טיפוס מסוג שלם – integer, וטיפוס מסוג מחרוזת – string), ושני טיפוסי נתונים המוגדרים בסכמה חיצונית (FlightInfoType ו- Ticket). WSDL מסוגל לייבא הגדרות XSD כאלו, בעזרת אלמנט "ייבוא" המציין את מיקומם.

    WSDL מגדיר אלמנטי הודעה כאוסף חלקים, כאשר כל אחד מהם מתואר ע"י טיפוסי XSD או ע"י אלמנטים מאוצר מילים שהוגדר מראש. ההודעות מספקות הגדרת טיפוס נתונים הנשלחת אל ומאת השירות. הדוגמא בתרשים (5) מציגה את שלוש ההודעות העלולות להופיע בעת התקשרות עם השירות. ההודעה GetFlightInfoInput מורכבת משני חלקים: airlineName – מחרוזת XSD, ו- flightNumber – מספר שלם XSD. שני ההודעות האחרות GetFlightInfoInput, ו- GetFlightInfoOutput בעלות חלק אחד כל אחת. האלמנטים operation ו- portType מרכיבים יחדיו הודעה המגדירה אינטראקציות. כל פעולה מייצגת תבנית של החלפת הודעות, בה תומך שירות הרשת, והדבר מאפשר למשתמשים גישה לחלק בסיסי מתפקוד אותו השירות. פעולה מלאה מול שירות הרשת היא בעצם שילוב של הודעות המתויגות כ- input, output או fault- סימון המציין איזה חלק אותה הודעה ממלאת בהתקשרות עם השירות.

    portType הוא אוסף של פעולות, שכולן נתמכות ע"י נקודת הקצה. בדוגמא שלנו, AiportServicePortType מתאר שני פעולות: פעולת בקשה-תגובה יחידה, GetFlightInfo, המצפה לקבל את הודעת GetFlightInfoInput כקלט ומחזירה כתגובה את הודעת GetFlightInfoOutput. ופעולה נוספת, חד כוונית – CheckIn, שלוקחת רק את הודעת CheckInInput כקלט.

    מידע הכרחי נוסף

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

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

    אלמנט ה"כריכה" (binding) של WSDL מספק את התשובה ל-"איזה" ו-"כיצד", כולל את פרוטוקול התקשורת ומפרט תבנית הנתונים, עבור portType מלא. בקצרה, אלמנט הכריכה מתאר לנו איך התקשרות נתונה מתרחשת על פרוטוקול מסוים.

    תרשים (6) מראה חלק מהדוגמא שלנו. הכריכה מתארת כיצד להשתמש ב- SOAP כדי לגשת לשירות travelservice.

    באופן פרטני יותר, ניתן לראות במסמך WSDL:

    • GetFlightInfo תהיה אינטראקציה בסגנון SOAP-RPC (קריאה לפרוצדורה מרחוק בעזרת SOAP), בה כל תעבורת ההודעות ישתמשו בקידוד SOAP סטנדרטי, ובנוסף
    • CheckIn הינה אינטראקציה המבוססת על הודעות בלבד ("מונחית-מסמכים" – Document Oriented, בשפת WSDL), בה גוף הודעת ה- SOAP מכיל את ההודעה בלא מידע נוסף (לגבי הקידוד עצמו), כלומר – נעשה שימוש ב-XSD כדי לתאר את תוכן ה- XML המשודר.

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

    השימוש ב- WSDL

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

    גילוי – UDDI

    מפרט ה- (Universal Description, Discovery, and Integration) UDDI מציע דרך אחידה ושיטתית למציאת ספקי שירותים, וניתן לומר שהוא מהווה מעין "מדריך טלפונים" של שירותי הרשת. מסד הנתונים העסקי של UDDI

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

    UDDI מספק שני מפרטים בסיסיים המגדירים את מבנה ופעולת מסד הנתונים:

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

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

    ייעול המבנה

    UDDI מקודד שלושה סוגי מידע עבור שירותי רשת:

    • "דפים לבנים" – דפי מידע הכוללים שם ופרטי התקשרות.
    • "דפים צהובים" – דפי מידע המספקים מידע המחולק לקטגוריות – על פי סוג עסק ושירות,
    • "דפים ירוקים" – דפי מידע המספקים מידע טכני על שירותי הרשת.

    מסד הנתונים של UDDI מאורגן סביב שתי ישויות המתארות עסקים והשירותים שהם מספקים. האלמנט businessEntity ("ישות עסקית") המודגםבתרשים (7) מספק מידע סטנדרטי, המצוי ב"דפים הלבנים", הכולל מזהים ייחודיים (מספר זהות, מספר בטוח לאומי וכו'), מידע לגבי יצירת קשר ותיאור קצר. כל ישות עסקית יכולה לכלול אלמנט businessService ("שירות עסקי") יחיד – או יותר, כמודגם בתרשים (8), המייצג את השירות/ים שהיא מספקת. שני אלה יכולים לציין catagoryBag ("קבוצת קטגוריות") כדי לשייך את העסק/השירות לקטגוריה מסוימת (מאוחר יותר נדון כיצד לקודד מידע זה).

    תרשימים (7) ו- (8) מציגים חלק חשוב ב- UDDI – מפתחות ייחודיים המזהים כל נתון – עסקים, שירותים וכו' – כך שניתן להפנות אליהם ממקום אחר. מפתחות אלה הם מחרוזות הקסדצימליות ארוכות המיוצרות כאשר היישות (במקרה זה – השירות) נרשמת ב- UDDI. מובטח כי המפתחות יהיו מזהים ייחודיים. לדוגמא, תכונת ה- businessKey ("מפתח העסק") מזהה באופן חד-חד-ערכי שירות מסוים. גם השירות מתייחס למארח שלו בעזרת מפתח העסק. בנוסף לתיאור קריא, שם וקטגוריה, השירות מכיל רשימה של bindingTemplates ("תבניות כריכה") המכילות מידע טכני לגבי הגישה לשירות. כל תבנית שכזו מייצגת נקודת גישה אל השירות. ההנחה העומדת בבסיס גישה זו היא שנקודות קצה שונות יכולות לספק את אותו השירות, ולכל אחת מהן יכולים תהיות מאפיינים טכניים שונים.

    תאוריים טכניים ו- tModels

    מבט מעמיק יותר בתבנית הכריכה (binding template) מראה כיצד UDDI מאפשר לתאורי העסק/שירות להשתמש במידע חיצוני ובלתי תלוי (כלומר מידע שלא הוגדר ע"י UDDI עצמו). רוב המידע בתבנית הכריכה הוא מידע שאנו, באופן טבעי, מצפים מנקודת קצה. החשובה ביותר היא כתובת נקודת הקצה – כך נוכל לגשת לשירות. כתובת זו יכולה להיות כתובת אינטרנט (URL), כתובת דואר אלקטרוני ואפילו מספר טלפון. אנו גם מצפים למפתח ייחודי (bindingKey) והתייחסות אל המפתח של השירות עצמו.

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

    כדוגמא, נניח שאנו מעוניינים לרשום מסמך WSDL כ- tModel. בהנחה שהוגדר ממשק WSDL סטנדרטי עבור בצוע Check In אלקטרוני וגישה למידע על טיסות (ע"י הגוף המתאים – במקרה זה תעשיית הנופש), אנו יכולים ליצור tModel כמו המתואר בתרשים (9), לשם ייצוג הגדרות WSDL אלו. נקודות קצה של השירות המשתמשות בממשקים אלה יכולות לכלול את ה- tModel המתאימים ברשימותיהן. כדי להיות יעילים יותר, על משתמשים ומפתחים של שירותים תואמים להיות מודעים ל- tModels הרשומים ולמזהים שלהם (המפתחות).

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

    מיון לקטגוריות

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

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

    • סווג תעשייתי, המתאים לתעשייה בצפון אמריקה (NAICS).
    • סווג ע"פ מוצרים ושירותים – המתאים לצורה הסטנדרטית של מיון מוצרים ושירותים (Universal Standard Products and Services Code System – UNSPSC).
    • סווג ע"פ אזור גאוגרפי, תואם את הסטנדרט ISO 3116
      (International Organization for Standardization Geographic taxonomy).

    ע"י חלוקה לקטגוריות, נוכל לבצע שאילתות מדויקות במסד הנתונים של UDDI. במקרה שלנו, נחפש שירות נסיעות המאפשר ביצוע Check-In באופן אלקטרוני, ופועל קרוב לאישור מגוריו של ג'ו. כשמצאנו את השירות המבוקש ב- UDDI, נוכל למצא את תיאור ה- WSDL המתאים לו כדי לדעת כיצד לתקשר עם השירות בעזרת הודעות SOAP וקריאות לפרוצדורות העזרת SOAP.

    ומה הלאה?

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

    אך מדוע, בעצם, אנו זקוקים לאבטחה נוספת, כאשר כבר קיימות טכנולוגיות כמו HTTP מאובטח (HTTP Secure – HTTPS), הרחבות אבטחה לדוא"ל (S-MIME – Secure Multipurpose Internet Mail Extensions), ו- Kerberos ? התשובה טמונה בהבדל בין תקשורת מקצה לקצה, לבין תקשורת אל נקודה בודדת. מסרים בד"כ מועברים מתוך ארגון אחד אל תוך ארגון אחר. מנגנונים המאבטחים שכבות תקשורת מסוימות טובים אם קיים קו ישיר ממכונה אחת לאחרת, אך אין אינם עוזרים כאשר על מסר לעבור דרך יותר מנתיב תקשורת אחד. לכן אנו זקוקים לאבטחה ברמת ה- SOAP.

    חוקרים כעת מגדירים מודלי אבטחה כתוספות למפרטים הקיימים. לדוגמא, הצעה עבור הרחבות אבטחה של (http://www.w3.org/TR/SOAP-dsig) SOAP מתארת כיצד ניתן להוסיף חתימה דיגיטלית להודעות SOAP. כמוכן מפותחים מפרטים עבור אימות, שמירה על סודיות ודרכי אישור בעזרת SOAP.

    היבט שני וחשוב הוא אמינות הפרוטוקול. גם פה נוכל, כמובן, להשתמש בשכבת הובלה (transport) אמינה, כמו HTTP אמין (Reliable HTTP – HTTPR), אך שוב – כאשר אנו משתמשים בתקשורת העוברת במספר רב של נקודות, אנו דורשים אמינות ברמת הודעת ה- SOAP. לכן, צפוי שיפותח סטנדרט "SOAP אמין" בקרוב.

    לבסוף, אינטראקציה עסקית מורכבת דורשת תמיכה עבור רמות תפקודיות גבוהות יותר. בפרט, אנו זקוקים לתיאור של איכות השירות (QoS Quality of Service -) שיש לשירות ולנקודות הקצה להציע. מצד שני, אינטראקציות בין-עסקיות הינן לרוב ארוכות וכוללת אינטראקציות רבות בין השותפים. כדי להפעיל באופן יעיל שירותים שכאלה, עלינו להיות מסוגלים ליצור חיבור בין שירותים (מצבור שירותים), באופן סטנדרטי ושיטתי. מספר הצעות לכך כבר הוגשו, ראה לדוגמא – שפת תיאור זרימת שירותי הרשת

    (Web Services Flow Language) [PDF file] , ושפת-X.

    מקורות נוספים

    אודות

    Translated from the original English version and reprinted with permission, from IEEE Internet Computing, vol 6, no 2 , pp 86-93. © 2002 IEEE.

    Francisco Curbera is a research staff member in the Component Systems group at IBM’s T.J. Watson Research Center. He received a PhD in computer science from Columbia University. He has worked for several years on the use of markup languages for application development and software- component composition. He is also coauthor of the WSDL and WSFL specifications.

    Matthew Duftler is a software engineer in the Component Systems group at IBM T.J. Watson Research Center. He was one of the original authors of Apache SOAP, and is the colead of JSR110, Java APIs for WSDL.

    Rania Khalaf is a software engineer in the Component Systems group at the IBM T.J. Watson Research Center. She received her BS and MEng in computer science and electrical engineering from MIT.

    William Nagy is a software engineer at IBM’s T.J. Watson Research Center. His research interests include the development of wide area distributed services and the infrastructure necessary to use and support them. His current focus is on Web services and includes the development of IBM’s Web Services Gateway and the WS-Inspection specification.

    Nirmal Mukhi is a research associate in the Component Systems group at the IBM T. J. Watson Research Center, where he does Web services research. He is codeveloper of the Web Services Invocation Framework.

    Sanjiva Weerawarana is a research staff member in the Component Systems group at IBM T.J. Watson Research Center. He is coauthor of the WSDL and WSFL specifications, and codeveloper of Apache SOAP, WSTK, WSDL Toolkit, WSIF, and WSGW. He received a PhD in computer science from Purdue University.

    Readers can contact the authors at {rkhalaf, sanjiva, curbera, duftler, nmukhi}@us.ibm.com.