שירותי אינטרנט ב- Java SE, חלק 1: סקירת כלים

המהדורה הסטנדרטית של Java (SE) 6 כללה תמיכה בשירותי אינטרנט. פוסט זה מתחיל סדרה בת ארבעה חלקים בנושא שירותי אינטרנט ב- Java SE בכך שהיא מסבירה מהם שירותי אינטרנט ומסקירה על התמיכה של Java SE בהם. פוסטים עתידיים ישתמשו בתמיכה זו לבניית שירותי אינטרנט מבוססי SOAP ו- RESTful, וכן יכסו נושאים מתקדמים לשירותי רשת.

Java XML ו- JSON

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

מהם שירותי רשת?

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

  • אינטרנט: רשת עצומה של משאבים המקושרים זה לזה, כאשר משאב הוא מקור נתונים בשם Uniform Resource Identifier (URI) בשם מקור כגון מסמך מבוסס PDF, זרם וידאו, דף אינטרנט או אפילו יישום. ניתן לגשת למשאבים אלה באמצעות פרוטוקולי אינטרנט סטנדרטיים כגון פרוטוקול העברת HyperText (HTTP) או פרוטוקול העברת דואר פשוט (SMTP).
  • שירות: יישום או רכיב תוכנה מבוסס שרת החושף משאב ללקוחות באמצעות חילופי מסרים על פי דפוס חילופי מסרים (MEP). חבר הפרלמנט האירופי לתגובה לבקשה אופייני.

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

איור 1. לקוח ניגש למשאב על ידי החלפת הודעות עם שירות אינטרנט

עסקים ושירותי אינטרנט

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

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

ארכיטקטורה מוכוונת - שירות

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

שירותי אינטרנט מבוססי SOAP

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

איור 2. פעולת שירות אינטרנט כוללת הודעות קלט ופלט

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

איור 3. נגישים לממשקי הפעולה דרך נקודות הקצה שלהם

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

בנוסף לתמיכה במסמכי WSDL, לשירותי אינטרנט מבוססי SOAP יש את המאפיינים הבאים:

  • היכולת לתת מענה לדרישות מורכבות שאינן פונקציונליות כגון אבטחה ועסקאות: דרישות אלה מוגשות באמצעות מפרטים שונים. כדי לקדם את יכולת הפעולה ההדדית בין מפרטים אלה, הוקם ארגון אינטראופרביליות שירותי אינטרנט (WS-I) (קונסורציום בתעשייה). WS-I הקימה מערך פרופילים, כאשר פרופיל הוא קבוצה של מפרט שירותי אינטרנט בשם ברמות תיקון ספציפיות, יחד עם קבוצה של הנחיות יישום והדדי פעולה, הממליצות כיצד ניתן להשתמש במפרטים לפיתוח שירותי אינטרנט אינטראופרטיביים. לדוגמא, הפרופיל הראשון ביותר, WS-I Basic Profile 1.0 , מורכב מהמערכת הבאה של מפרטי שירות האינטרנט הלא-תקינים:
  • סבון 1.1
  • WSDL 1.1
  • תיאור אוניברסלי גילוי ואינטגרציה (UDDI) 2.0
  • XML 1.0 (מהדורה שנייה)
  • סכמת XML חלק 1: מבנים
  • סכמת XML חלק 2: סוגי נתונים
  • RFC2246: פרוטוקול האבטחה של שכבת התחבורה גרסה 1.0
  • RFC2459: אישור תשתיות מפתח ציבוריות באינטרנט X.509 ופרופיל CRL
  • RFC2616: פרוטוקול העברת HyperText 1.1
  • RFC2818: HTTP על TLS
  • RFC2965: מנגנון ניהול המדינה של HTTP
  • פרוטוקול השכבה Secure Sockets Layer גרסה 3.0

דוגמאות פרופיל נוספות כוללות פרופיל אבטחה בסיסי של WS-I ופרופיל פשוט של קשירת SOAP. למידע נוסף על פרופילים אלה ואחרים, בקרו באתר WS-I. Java SE תומך בפרופיל הבסיסי של WS-I.

  • היכולת לקיים אינטראקציה עם שירות אינטרנט בצורה אסינכרונית: לקוחות שירות האינטרנט צריכים להיות מסוגלים לתקשר עם שירות אינטרנט באופן חסום ואסינכרוני. תמיכה בהפעלה אסינכרונית בצד הלקוח של פעולות שירות האינטרנט ניתנת ב- Java SE.

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

איור 4. שירות אינטרנט מבוסס SOAP כולל מבקש שירות, נותן שירות ומתווך שירותים (למשל UDDI)

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

יש לפרסם ספקי שירות כדי שאחרים יוכלו לאתר אותם ולהשתמש בהם. באוגוסט 2000 הושקה יוזמה בתעשייה פתוחה המכונה UDDI Universal Description, Discovery, and Integration, המאפשרת לעסקים לפרסם רשימות שירותים, לגלות זו את זו ולהגדיר את האופן שבו השירותים או יישומי התוכנה מתקשרים באינטרנט. עם זאת, רישום מבוסס-XML שאינו תלוי בפלטפורמה לא אומץ באופן נרחב וכיום לא נעשה בו שימוש. מפתחים רבים מצאו ש- UDDI מורכב מדי וחסר פונקציונליות, ובחרו בחלופות כמו פרסום המידע באתר. לדוגמה, גוגל הפכה פעם אחת את שירותי האינטרנט הציבוריים שלה (למשל, מפות גוגל) לזמינים בכתובת //code.google.com/more/.

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

שירותי אינטרנט גדולים

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

שירותי אינטרנט רגועים

ניתן להעביר שירותי אינטרנט מבוססי SOAP באמצעות פרוטוקולים כגון HTTP, SMTP, FTP ו- Blocks Extensible Exchange Protocol (BEEP). העברת הודעות SOAP באמצעות HTTP יכולה להיראות כסוג מיוחד של שירות אינטרנט RESTful.

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

היסטוריית REST

רוי פילדינג (מחבר ראשי של מפרט ה- HTTP בגרסאות 1.0 ו- 1.1, ומייסד קרן אפאצ'י תוכנה) הציג והגדיר את REST בעבודת הדוקטורט שלו בשנת 2000. פילדינג ראה את REST כסגנון האדריכלי של הרשת, למרות שכתב זה התרחש הרבה אחרי שהאינטרנט היה עניין מתמשך. REST נחשב נרחב כפתרון למה שנחשב למורכבות ההולכת וגוברת של שירותי אינטרנט מבוססי SOAP.

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

לקוחות משתמשים בפעלים POST, GET, PUT ו- DELETE של HTTP כדי לאחזר ייצוגי משאבים ולתפעל משאבים. REST ממפה את הפעלים הללו על פעולות היצירה, הקריאה, העדכון והמחק (CRUD) של מסד הנתונים, כדלקמן:

  • POST: צור משאב חדש על סמך נתוני בקשה.
  • GET: קרא את המשאב הקיים מבלי לייצר תופעות לוואי (אל תשנה את המשאב).
  • שים: עדכן את המשאב הקיים בנתוני בקשה.
  • מחק: מחק את המשאב הקיים.

אחרי כל פועל מופיע URI המזהה את המשאב. (גישה פשוטה מאוד זו אינה עולה בקנה אחד עם גישת SOAP של שליחת הודעות מקודדות למשאב יחיד.) ה- URI עשוי להתייחס לאוסף, כמו למשל //javajeff.ca/library, או לאלמנט באוסף, כגון //javajeff.ca/library/9781484219157- URI אלה הם רק איורים.

לבקשות POST ו- PUT, נתוני משאבים מבוססי XML מועברים כגוף הבקשה. לדוגמה, תוכל לפרש POST //javajeff.ca/library HTTP/ 1.1(כאשר HTTP/ 1.1מתאר את גרסת ה- HTTP של המבקש) כבקשה להכניס POSTאת נתוני ה- XML //javajeff.ca/libraryלמשאב האיסוף.

עבור בקשות GET ו- DELETE, הנתונים מועברים בדרך כלל כמחרוזות שאילתה, כאשר מחרוזת השאילתה היא החלק הזה ב- URI המתחיל ?בתו. לדוגמא, איפה GET //javajeff.ca/libraryעשוי להחזיר רשימת מזהים לכל הספרים libraryבמשאב, GET //javajeff.ca/library?isbn=9781484219157כנראה שיחזיר ייצוג של משאב הספר שמחרוזת השאילתה שלו מזהה את מספר הספרים הסטנדרטי הבינלאומי (ISBN) 9781484219157.

למידע נוסף על מיפויי HTTP-CRUD

לתיאור מלא של המיפוי בין פעלים HTTP לעמיתיהם CRUD, עיין בטבלה "שיטות HTTP בשירות אינטרנט RESTful" בערך העברת מדינות ייצוגיות בוויקיפדיה.

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

מנוחה לעומת שירותי אינטרנט גדולים

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

תמיכה בשירות אינטרנט ב- Java SE

לפני Java SE 6, שירותי אינטרנט מבוססי Java פותחו אך ורק עם Java Enterprise Edition (EE) SDK. למרות ש- Java EE מועדף לפיתוח שירותי אינטרנט מנקודת מבט של ייצור, מכיוון ששרתים מבוססי Java EE מספקים מידה גבוהה מאוד של מדרגיות, תשתית אבטחה, מתקני ניטור וכן הלאה, פריסה חוזרת של שירות אינטרנט ל- Java EE. מיכל לקח לעתים קרובות זמן רב, והאט את ההתפתחות. Java SE 6 פשט ומהיר את פיתוח שירותי האינטרנט על ידי הוספת ממשקי API, ביאורים, כלים ושרת HTTP קל משקל (לפריסת שירותי אינטרנט לשרת אינטרנט פשוט ובדיקתם בסביבה זו) אל ליבתו.

ממשקי API

Java SE מספק מספר ממשקי API התומכים בשירותי אינטרנט. יחד עם ממשקי API שונים של JAXP (SAX, DOM, StAX, וכן הלאה) עליהם אני דן ב- Java XML ו- JSON , Java SE מספקת את ממשקי ה- API של JAX-WS, JAXB ו- SAAJ: