קולוריס הגדירה מערכות מבוזרות כ"מערכות שבהן רכיבי חומרה ו/או תוכנה הקיימים ברשת מחשבים מתקשרים ומתאמים את פעולותיהם על ידי החלפת מסרים".
מושג זה הפך פופולרי בשנים האחרונות בגלל מספר גורמים. הגורם הראשון שקידם את הפיתוח של מערכות מבוזרות היה הופעתן של רשתות מקומיות מהירות. גורם חשוב נוסף היה התקדמות טכנולוגית בביצועי מחשבים אישיים ופיתוח תוכנות לתמיכה ביישומים מבוזרים. מערכות מבוזרות מקושרות למושג אינטרנט ואינטרנט. עם התפתחות האינטרנט, והופעת תחומים, אינטראקציות, צרכים ויישומים חדשים, עולה הרעיון של Web 2.0. מונח זה נטבע על ידי טים אוריילי בשנת 2004 כדי להתייחס לדור שני בהיסטוריה של האינטרנט המבוסס על קהילות משתמשים ומגוון מיוחד של שירותים, כגון רשתות חברתיות, בלוגים, ויקי או פולקסונומיה, המעודדים שיתוף פעולה וזריז. החלפת מידע בין משתמשים.
הארכיטקטורות הראשונות שיכולות להיחשב מוכוונות שירות (SOA) התבססו על CORBA (Common Object Request Broker Architecture), אשר פעלה כשכבת הפשטה לחיבור בין האלמנטים השונים של הארכיטקטורה ובניית שירותים. טכנולוגיות מוקדמות אחרות היו DCOM (Distributed Component Object Model) או RPC (Remote Protocol Protocol). עם הצורך לתכנן ולהטמיע מערכות מבוזרות ברשת בצורה יעילה, מתעוררים מספר אתגרים, חלקם מתמקדים בפיתוח עצמו (ביצועים, חווית משתמש וכו') ואחרים משלימים, המבוססים על שימוש חוזר ותאימות שירותים. מצרכים אלו נובעים שירותי אינטרנט, המספקים מנגנונים סטנדרטיים לחיבור בין משתמשים שונים לשרתי מידע.
ארכיטקטורות מכוונות שירות
על פי SOA (Service Oriented Architecture) הן ארכיטקטורות תוכנה שמגדירות את השימוש בשירותים לתמיכה בדרישות עסקיות, שמטרתן היא להשיג את המינימום הצימוד האפשרי בין סוכני תוכנה. שירות הוא יחידת עבודה המבוצעת על ידי ספק שירות להשגת תוצאה סופית הרצויה על ידי צרכן שירות. גם ספק השירות וגם צרכן השירות הם תפקידים של סוכני תוכנה, לא בעליהם. במובן הכללי, ארכיטקטורה מוכוונת שירות היא פתרון תוכנה שנועד לאפשר לחברה להתארגן ולעשות שימוש בתהליכים שונים. עם SOA, יישומי תוכנה אינם עוד בלוקים ענקיים של פונקציות ותהליכים. במקום זאת, יישומים אלה מורכבים משירותים מודולריים מורכבים. זכור ששירות הוא פונקציית תוכנה פשוטה (כמו ביטול השמעה בתקליטור). ניתן להפעיל אותו לפי דרישה על ידי כל מערכת, ללא קשר למערכת הפעלה, פלטפורמה, שפת תכנות או מיקום גיאוגרפי.
מה שמהפכני ב-SOA הוא לא הרעיון עצמו, שקיים כבר הרבה זמן, אלא העובדה שניתן ליישם אותו דרך ה-WWW (World Wide Web). בדיוק כמו שדפי אינטרנט נטענים בכל פלטפורמה, שירותי אינטרנט פועלים בצורה דומה ללא קשר לפלטפורמה כפי שהם בנויים באמצעות
סטנדרטים אוניברסליים.
הרעיון של SOA נובע ישירות מתכנות מונחה עצמים, מה שמרמז על קשר בין נתונים ועיבודם. לפיכך, הם מגדירים רשמית שירותים באמצעות ממשקים שאינם תלויים בפלטפורמה הבסיסית ובשפת התכנות. ממשקים אלה מסתירים את המוזרויות של היישום שלהם, מה שהופך אותם לבלתי תלויים ב- שפת מפתחים ושפת תכנות. באמצעות ארכיטקטורות אלו, ניתן לתכנן ולהטמיע מערכות ניתנות להרחבה המשקפות היגיון עסקי ובו בזמן מקלות על אינטראקציה בין מערכות קנייניות שונות או מערכות צד שלישי. הסיבה שאנחנו רוצים שמישהו יעשה את העבודה בשבילנו היא בגלל שהוא מומחים. השימוש בשירות הוא בדרך כלל זול ויעיל יותר מאשר לעשות זאת בעצמך. אז רובנו מבינים שאנחנו לא יכולים להיות מומחים בכל דבר. את אותו כלל ניתן להחיל על בניית מערכות תוכנה.
ממשקים חשובים ביותר, אם הם לא מוגדרים היטב או לא עובדים, המערכת לא עובדת. שילוב של יותר ממשקים הוא יקר וגם מגביר את האפשרות לשגיאות באפליקציות מבוזרות. ממשקים מרוחקים הם החלק האיטי ביותר של רוב היישומים המבוזרים. עם כל זה, במקום לבנות ממשקים חדשים לכל אפליקציה, הגיוני יותר לעשות שימוש חוזר בממשקים גנריים עבור כל האפליקציות.
לכן, מכיוון שיש לנו רק כמה ממשקים גנריים זמינים, עלינו לכלול סמנטיקה ספציפית ליישום בהודעות. אנחנו יכולים לשלוח כל סוג של הודעה דרך הממשקים שלנו, אבל יש כמה כללים שיש לפעול לפיהם כדי לומר שארכיטקטורה היא מוכוונת שירות.
– ראשית, הודעות חייבות להיות תיאוריות, לא מאלפות, שכן נותן השירות אחראי לפתרון הבעיה. לדוגמה, זה יהיה דומה למצב של ללכת למסעדה ולהגיד למלצר מה תרצה לשתות והעדפותיך, אך אל לנו להסביר לטבח כיצד להכין את המנות שלך, צעד אחר צעד.
שנית, נותני השירות לא יוכלו להבין את בקשתך אם ההודעות שלהם לא כתובות בפורמט, מבנה ואוצר מילים המובנים לכל המעורבים. לפיכך, הגבלת אוצר המילים ומבנה המסרים היא א
הכרחי לתקשורת אפקטיבית. ככל שהמסר מוגבל יותר, כך קל יותר להבין אותו.
שלישית, לאפשרות הרחבות יש חשיבות חיונית. העולם הוא מקום שמשתנה ללא הרף, וכך גם הסביבה שבה חיה התוכנה. שינויים אלו דורשים שינויים תואמים בתוכנת המערכת, לצרכנים של שירותים, ספקים וההודעות שהם מחליפים. אם ההודעות אינן ניתנות להרחבה, הצרכנים והספקים יהיו נעולים לגרסה ספציפית של השירות. אילוץ והרחבה קשורים קשר עמוק, אתה צריך את שניהם, והגדלה של אחד פירושה צמצום השני. האידיאל הוא להשיג איזון נכון.
– רביעית, SOA חייב להיות בעל מנגנון המאפשר לצרכן לגלות ספק שירות בהקשר של שירות המבוקש על ידי הצרכן. המנגנון חייב להיות גמיש ואסור להיות רישום מרכזי.
- חמישית, שירות חסר מדינה: כל הודעה שצרכן שולח לספק חייבת להכיל את כל המידע הדרוש לספק כדי לעבד אותה. הגבלה זו הופכת את ספק השירות לניתן להרחבה יותר מכיוון שהספק אינו צריך לאחסן מידע מצב בין בקשות. זה יכול להיקרא "שירות ייצור המוני", שכן ניתן לטפל בכל בקשה באופן כללי. הגבלה זו גם מספקת יותר נראות, שכן כל תוכנת ניטור יכולה לבדוק בקשה עצמאית ולחלץ את כוונתה. זה גם מאפשר התאוששות קלה מתקלות חלקיות מכיוון שאין מצבי ביניים, מה שהופך את השירות לאמין יותר.
- שישית, בקשות חסרות כוח (שאינן מבצעות שינויים): בקשות כפולות שמתקבלות על ידי סוכן תוכנה בעלות השפעה זהה לבקשה בודדת. דרישה זו מאפשרת לספקים ולצרכנים להגביר את האמינות הכוללת של שירות, פשוט לחזור על הבקשה אם התרחש כשל כלשהו.
אז אנחנו יכולים לומר ש-SOA הוא לא כלי, אלא סט של סטנדרטים לבניית יישומים חדשים, דינמיים יותר ופחות תלויים. SOA מאפשר גישה להיגיון עסקי ולמידע בין שירותים שונים בצורה שיטתית, ויכול גם לתזמן מספר שירותים מרוחקים ליצירת אחד אחד. הרוב של ההגדרות מזהות את השימוש ב-Web Services, אותו נראה בפרק הבא, ביישום ארכיטקטורה מוכוונת שירות. עם זאת, ניתן ליישם אותו באמצעות כל טכנולוגיה אחרת מבוססת שירות.