בארכיטקטורת SOA השירותים הם למעשה אבני הבניין של יישומים. אנלוגיה פשטנית המתארת את מודל הרכבת היישומים מהשירותים היא בנייה באמצעות אבני לגו. בתהליך זה מתבצע חיבור קל בין אבנים שונות המאפשר הרכבת עצמים שונים באמצעות צירופים שונים של אותן אבנים. לשירות עשויים להיות מספר רב של צרכנים. המושג צרכן אינו שווה ערך למושג לקוח שמתקיים בארכיטקטורות קודמות כגון שרת-לקוח (Client-Server), זאת משום שלקוח הוא עמדת קצה מולה יושב משתמש אנושי, בעוד צרכן עשוי להיות לקוח אך יכול להיות גם שירות אחר. ארכיטקטורה מוכוונת שירותים משמשת לאינטגרציה בין יישומים ולבניית יישומים.
קישור בין השירות לצרכן מתבצע באמצעות ממשק כמתואר באיור להלן:
Service
Service Interface
Consumer Interface
Consumer
בעיני רבים, SOA נחשבת לארכיטקטורה ארגונית מכיוון שהיא משתרעת על פני רבדים רבים בארגון, הן עסקיים והן טכניים. SOA מציגה תפיסה מופשטת יותר מקודמותיה ובנוסף מבוססת במקרים רבים על תקנים פתוחים.
הגדרת SOA
לארכיטקטורות מוכוונות שירותים יש מספר רב של הגדרות תאורטיות או מעשיות השונות זו מזו. המאפיינים הבאים משותפים למרבית ההגדרות המוכרות:
מנשר ארכיטקטורה מוכוונת שירותים או באנגלית SOA Manifesto הוא מנשר קצר המציג עקרונות וקווים מנחים ביישום ארכיטקטורות מוכוונות שירותים או באנגלית SOA. הכרזת המסמך נעשתה ב 26 באוקטובר 2009, על ידי קבוצת אנשים מובילים בעולם בתחום.
מטרת ההכרזה היא יצירת מסמך שישמש מסמך התייחסות עיקרי לקהיליית מממשי SOA בארגונים ועל ידי כך יאפשר מימושים מוצלחים יותר של ארכיטקטורה זו. המניעים העיקריים להכרזה הם:
המספר הרב של מימושים לא מוצלחים של ארכיטקטורת SOA, שבעטים נוצרה תחושה של אכזבה מתפיסה מוכוונת שירותים. הביטוי הבולט ביותר של האכזבה הופיע בפוסט בבלוג של אן תומאס-מנס סגן נשיא ומנהלת מחקר בחברת Burton Group שכותרתו הייתה: SOA is Dead Long live Services.
הצלחת מנשר לפיתוח תוכנה זריז שפורסם בשנת 2001 והביא להתקדמות עצומה בתחום של פיתוח תוכנה זריז. מניתוח הסיבות להצלחת המנשר לפיתוח תוכנה זריז התברר שהסיבות היו: היותו מסמך פשוט וקצר והעובדה שהחותמים היו האנשים המובילים בתחום. הוגי הרעיון של מנשר ארכיטקטורות מוכוונות שירותים פעלו באופן דומה.
במנשר זה כמו במנשר לפיתוח תוכנה זריז, אנשים העוסקים בנושא יכולים להוסיף את חתימתם.
היסטוריה
ב-40 שנות המחשוב הראשונות, מערכות המידע היו מערכות מונוליתיות, כלומר מערכות הנבנות כל אחת בנפרד ובדרך כלל גם ללא תכנון מראש של אינטגרציה עם מערכות אחרות. החסרונות של מודל זה התבררו בעיקר בשנות ה-90 של המאה העשרים והביאו לניסיונות שונים לפרק את המערכות המונוליטיות לרכיבים. תחום נוסף של ניסיונות לשיפור ארכיטקטורת המערכות כלל ניסיונות לשילוב בין מערכות שונות. ארכיטקטורות מוכוונות שירותים (SOA) הן אחד מניסיונות אלה.
ניסיונות לבניית מערכות באמצעות רכיבים מתוארים להלן:
מונחה אובייקטים (Object Oriented): תפיסה זו מתייחסת לחלוקה לרכיבים ברמת תוכנית. החלה בשנות ה-60 עם הופעת שפות תכנות כמו Smalltalk ובהמשך בשנות השמונים C++, והפכה למרכזית החל משנות ה-90 בהן נוצרה שפת Java.
פיתוח מבוסס רכיבים (CBD): תפיסה זו היא מתייחסת לחלוקה לרכיבים ברמת מערכת. תפסה מקום חשוב החל משנות ה-90. המודלים הבולטים בתחום היו CORBA ו-DCOM/COM. CORBA היה מודל מורכב ופתוח לפלטפורמות שונות. COM/DCOM היה מודל של מיקרוסופט הישים בעיקר למערכת ההפעלה Windows. בסוף שנות ה-90 התווסף מודל של EJB בעולם ה-JAVA. מודל רכיבים חשוב נוסף קיים במהדורה 2.0 של UML.
רכיבי אפליקציות מוכנות: חבילות האפליקציות המוכנות כגון ERP ו-CRM התבססו על חלוקה לרכיבים. אף על פי שמושג הרכיב (Component) משתמש במילה זהה לרכיב של פיתוח מבוסס רכיבים, ההגדרות מתייחסות לישויות שונות לחלוטין. בהקשר של האפליקציות המוכנות מדובר למעשה ברכיבים גדולים במיוחד שהם שווי ערך בהיקפם לאפליקציות המונוליטיות כך שלמעשה אין מדובר בחלוקה ממשית לרכיבים אלא במודל מונוליטי משופר בו המערכות המונוליטיות משתפות מודל נתונים, רוטינות ותוכניות שירות ו-API. הוכחה לטענה זו ניתן לראות בתהליכי בנייה חדשים של אפליקציות אלה בתפיסת SOA.
מכוון שירותים: שירות הוא היחידה הבסיסית של SOA. היחידות הבסיסיות אלו הן רכיבים ברמת הארגון או הארגון הווירטואלי ולא ברמת מערכת בודדת, כלומר: עשוי להתבצע בהם שימוש חוזר במערכות שונות בארגון ומחוצה לו.
ראשיתן של ארכיטקטורות מוכוונות שירותים היא בשנת 1996. בשנה זו התייחסו אנליסטים של חברת Gartner למושג זה. ארגונים מעטים, כגון הבנק Credit Swiss החלו ביישום ארכיטקטורה זו. רק החל מתחילת שנות ה-2000 הפכה ארכיטקטורה מוכוונת שירותים למגמה מרכזית במערכות מחשוב. תרומה רבה לכך יש להיווצרות סטנדרטים של Web Services ולצורך לתת מענה לצרכים העסקיים המשתנים.
היום SOA היא פרדיגמה מובילה בתחום מערכות מחשוב כשיותר ויותר ארגונים מתחילים לבצע מעבר אליה. יצרני תוכנת התשתית המובילים יבמ, מיקרוסופט, Oracle, SAP, BEA ויצרנים רבים נוספים פיתחו מוצרי תוכנה התומכים במימוש SOA.
חרף זאת תהליך שינוי הפרדיגמה השלטת במחשוב לארכיטקטורה מוכוונת שירותים הוא בתחילת דרכו, מה שמביא לכך שחלק מהניסיונות לעבור לעבודה בתפיסה זו נכשלים ומוצרי התוכנה הייעודיים לנושא טרם הבשילו באופן מלא.
כיוונים חדשים יחסית במסגרת התפתחות והבשלת ארכיטקטורת מוכוונות שירותים הם SOA 2.0 ו-WOA.
הארכיטקטורה
ארכיטקטורה מוכוונת שירותים היא ארכיטקטורה מופשטת המורכבת ממספר שכבות הקשורות ביניהן.
ארכיטקטורה עסקית
מתארת את השירותים העסקיים והקשרים ביניהם ואת התהליכים העסקיים והקשרים בינם לבין תהליכים אחרים ובינם לבין שירותים עסקיים. אינה מכילה מרכיבים מחשוביים טכנולוגיים.
ארכיטקטורת תוכנה
כוללת מאפיינים טכנולוגיים ומחשוביים ומורכבת ממספר רבדים או מרכיבים כמתואר להלן:
ארכיטקטורה יישומית מתארת מרכיבים יישום כגון: שירותים ממוחשבים הממופים מול שירותים עסקיים, תהליכים ממוחשבים הממופים מול תהליכים עסקיים, מערכות יישומיות, למשל: מערכת הלוואות, מערכת חסכונות ומערכת פיקדונות בבנקאות, מערכת חיתום בביטוח, מערכת CRM בכל המגזרים הארגוניים.
מטא דאטה או בלועזית Metadata המתייחס לנתונים על נתונים.
ארכיטקטורת התוכנה היא ארכיטקטורה מופשטת, כלומר: ממפה משאבי תוכנה לשכבה מופשטת יותר של שירותים.
הארכיטקטורה כוללת גם תיאור של צד הצרכן. אלמנט זה מתואר באמצעות ארכיטקטורת ריבוי-ערוצים או בלועזית Multi-Channel Architecture.
האיור להלן מדגים מימוש ארכיטקטורת SOA באופן סכמטי.
ארכיטקטורת ביצוע של SOA
באיור ניתן לראות את הדברים העיקריים הבאים:
השכבות העיקריות הן השירותים העסקיים והתהליכים העסקיים המיוצגות באמצעים מחשוביים.
השירותים המופשטים ממומשים באמצעות ישויות תוכנה. הישויות מודגמות באמצעות החלק התחתון של האיור. הן עשויות לכלול: שירותים, רכיבי תוכנה שפותחו בארגון, אפליקציות מוכנות, כגון (Enterprise Resource Planning (ERP), (Customer Relationship Management (CRM ומקורות מידע, כגון: בסיסי נתונים.
מיפוי משאבים ומרכיבים לשירותים, נעשה באמצעות מנגנוני אינטגרציה המשלבים מספר מרכיבים לשירות אחד. באיור מופיעים תיאורים גרפיים שונים בשכבת האינטגרציה המייצגים מנגנונים שונים. המנגנונים השונים מגדירים סוגי שירותים שונים.
הצרכן משתמש בשירותים ובתהליכים. צד הצרכן עשוי להראות ארכיטקטורת ריבוי-ערוצים או צרכנים בודדים במצב של טרום ארכיטקטורת ריבוי-ערוצים. קיימים ארבעה סוגי שירותים:
שירות חדש (New Serevice): שירות כזה נבנה ותכנן מראש בתפיסה מוכוונת שירותים. הצד השמאלי של שכבת האינטגרציה באיור מתאר שירות כזה. בגלל התכנון מראש דפוס האינטגרציה הוא פשוט.
שירות עטוף (Wrapped Service): עיטוף פונקציונליות קניינית קיימת כשירות. העטיפה מאפשרת שימוש בפונקציונליות באמצעות ממשק סטנדרטי.
שירות מורכב (Composite Service): השירות כולל פונקציונליות מכמה מקורות: יישומים קנייניים, יישומים מוכנים (כגון: ERP או CRM) ושירותים חדשים.
שירות נתונים (Data Service): השירות אינו מספק פונקציונליות (או מספק פונקציונליות מזערית). הוא מספק נתונים שעשויים להיגזר ממקורות שונים.
מושגים
חוזה שירות (Service Contract)
מסמך חיצוני לשירות המתאר את מאפייני רמת השירות המוסכמת (SLA) בין נותן השירות לצרכני השירות. ה-SLA בארכיטקטורת SOA נבנה ברוב המקרים באמצעות מסמך XML. חוזה שירות מכיל את המרכיבים הבאים:
Header - חלק בתחילת המסמך הכולל מאפיינים מזהים (שם השירות, מהדורת חוזה השירות), סוג השירות (כגון: שירות אינטגרציה, שירות נתונים, שירות שהוא תהליך), מאפיינים ניהוליים: שם האחראי (owner) על השירות, תפקיד האדם או הצוות האחראים, תפקיד ושם האחראי הניהולי, גורמים אתם יש להתייעץ לפני שינויים בחוזה וגורמים אותם יש לידע במקרה של שינוי החוזה. מאפיינים ניהוליים אלה מתוארים באמצעות ראשי התיבות אנימ (RACI באנגלית): אחראי (Responsible), ניהולי (Accountable), יעוצי (Consulted), מיודע (Informed).
מאפיינים פונקציונליים - תיאור מעשי של הפונקציונליות של השירות המבוסס על מסמך דרישות פונקציונליות, חלוקה של השירות לפעולות (Operations) המתבצעות על ידו, אופני הפעלה (Invocation) אפשריים שלו (למשל באמצעות פרוטוקול SOAP או באמצעות פרוטוקול REST) וממשקים בין השירות לצרכן.
מאפיינים לא פונקציונליים - דרישות תפעוליות שאינן מתייחסות לפונקציונליות, לחלוקתה ולאופן הפעלתה אך מהוות בסיס לניהול השירות בזמן ריצה. בחלק זה נכללים מגבלות אבטחת מידע, אבטחת שירות, ביצועים, סמנטיקה, מאפיינים טרנזקציונליים וכיוצא בזה.
מודל ההתייחסות הוא ארכיטקטורת SOA כללית הנבנית על ידי גוף המטפל בתקינה למשל OASIS[1] או יצרן תוכנה (לכל אחד מיצרני התוכנה הבולטים בתחום יש מודל התייחסות משלו).
המודל משמש כנקודת התחלה לבניית ארכיטקטורת SOA ספציפית המותאמת לארגון באמצעות ביצוע שינויים והתאמות למודל.
מדוע ארכיטקטורה מוכוונת שירותים?
סיבה עיקרית למעבר לארכיטקטורה מוכוונת שירותים היא הצורך להתאים את המערכות הממוחשבות והתהליכים הממוחשבים לקצב ההולך וגובר של שינויים עסקיים. דרישה זו נקראת ארגון מגיב. ארכיטקטורת SOA מאפשרת את הגמישות הנדרשת להתאמתה מהירה של מערכות המחשוב לשינויים אלה.
סיבות עסקיות נוספות למעבר לארכיטקטורה מכוונת שירותים
מיזוגים ורכישות: היתרון העסקי לגודל והגלובלזיציה גורמים למיזוגים ורכישות במרבית המגזרים העסקיים. רכישות מחייבות שילוב מהיר של תשתיות מחשוב ומערכות מחשוב יישומיות. ארכיטקטורות מכוונות שירותים מאפשרות זאת.
פיצול חברות (רגולציה, Spin offs, מכירת קו עסקים): פיצול חברות הוא תמונת הראי של רכישות. מחייב הפרדה מהירה של מערכות מחשוב ותהליכים ארגוניים. גם בנושא זה התפיסה של ארכיטקטורות מכוונות שירותים מתאימה במיוחד למימוש דרישה זו.
גמישות תהליכים עסקיים
קצב השינוי העסקי המהיר מחייב שינוי מתמיד של תהליכים עסקיים. הגמישות של ארכיטקטורה מוכוונת שירותים תומכת היטב בדרישה זו.
Real Time Enterprise : מענה עסקי בזמן מיידי מהווה גורם קריטי להצלחה. מחייב שינויים מהותיים במערכות וארכיטקטורות המחשוב, שלא נבנו לתמוך לעבודה בתפיסה זו.
ריבוי ערוצים (Multi-Channel) : שימוש במספר רב של ערוצים, שכולם צריכים להפעיל את אותן מערכות Back office. חשוב במיוחד בבנקאות ובמגזר חברות התעופה. מימוש העקרונות של אי-תלות בין צרכן לשירות ותמיכה בריבוי יחידות צרכן הכלולים ב SOA מספק מענה לצורך זה.
Time to Market: הגדלת התחרות והאופי הדינאמי של העסקים מחייבים מימוש מהיר של מוצרים בתחום ההתמחות של החברה או הארגון.
סיבות טכנולוגיות נוספות למעבר לארכיטקטורה מכוונת שירותים
עלויות תחזוקה גבוהות: התחזוקה היא בין 60% ל 80% מתקציבי טכנולוגיית המידע (IT) בארגונים ובשל כך קיים קושי בהקצאת משאבים לקידום העסק. ארכיטקטורות מוכוונות שירותים מאפשרות שימוש חוזר המקטין את הצורך בתחזוקה ומאפשרות תקשורת טובה יותר בין אנשי עסקים ואנשי מחשוב המקטינה אף היא את כמות התחזוקה הנדרשת.
עלויות פיתוח יקרות: איסוף שירותים להקמת מערכות ואיסוף שירותים לבניית תהליכים מקטינים את כמות הפיתוח הנדרש.
איכות ועקביות נמוכים של נתונים: שירותי נתונים חוסכים שכפול והעתקה של נתונים, שממנו נובעות במקרים רבים בעיות של איכות ועקביות נמוכה.
קשיים באינטגרציה: העיקרון של חשיבה מראש על אינטגרציה והשימוש בסטנדרטים מקלים על מימוש אינטגרציה בין מערכות בארגון ובין מערכות בארגון ומערכות חיצוניות.
התאמה לחידושים טכנולוגיים: התפיסה המבוססת על מודלריות של שירותים מקלה על הוספת תשתיות טכנולוגיות חדשות ועל החלפת תשתיות בתשתיות טכנולוגיות חדשות.
Do More with Less: מנהל מערכות מחשוב ראשי (CIO) נדרש להפיק יותר תוצרים בפחות משאבים. בגלל כל התועלות שצוינו לעיל, תפיסה מכוונת שירותים עשויה לאפשר לו להתמודד עם אתגר זה.
SOA ו-Web Services
SOA וWeb Services
יש המזהים בין SOA ל-Web Services. זיהוי זה אינו נכון ואינו מדויק ברמה התאורטית ועשוי להיות בעייתי ברמה הפרקטית.
אחת הבעיות בזיהוי כזה היא, שלהגדרה של SOA, מתווסף אוטומטית צימוד רפוי (Loose Coupling), משום שזו צורת העבודה של Web Services.
בפועל ישנם ארגונים שמימשו SOA באמצעות טכנולוגיות אחרות, למשל: Credit Swiss באמצעות CORBA.
אחד ההבדלים המהותיים הוא ש-SOA אסטרטגי במהותו ולכן יש לו השלכות עסקיות, ארגוניות וטכנולוגיות מהותיות.
Web Services הם טקטיים. ארגון מנסה לפתור בעיה נקודתית של אינטגרציה. מגיע למסקנה ששימוש ב-Web Services מתאים (בדרך כלל משיקולים של עלות וזמן פיתוח) ומיישם Web Service. בעיות נקודתיות נוספות, עשויות להיפתר באופן דומה על ידי Web Services נוספים.
מימוש של Web Services הוא בתפיסה של Bottom-Up, כלומר: מלמטה למעלה או מהבעיות הנקודתיות לארגון כלו, בעוד מימוש SOA מבוסס במקרים רבים על תפיסה של Top-Down, כלומר: מתכנון כולל כלפי מטה. בגלל מורכבות מימוש SOA, אין די בגישת Top-Down ובמקרים רבים נדרש גם שילוב של גישת Bottom-UP.
עם זאת המשותף בין SOA ל-Web Services, הוא האלמנטים הבסיסיים בשניהם: שירותים וממשקים.
יש הרואים ב Web Services טכנולוגיה מאפשרת (Enabling Technology) ל-SOA.
בפועל המימושים העכשוויים של SOA מבוססים בחלקם ברוב המקרים על Web Services.
חברת האנליסטים Burton Group טבעה את המושג Web Services framework או בקיצור WSF, המתאר SOA הממומש באמצעות Web Services. האיור בראש פרק זה מסכם באופן גרפי את הקשר בין SOA ל-Web Services: אין זהות אבל יש חפיפה חלקית. מחד קיים SOA ללא שימוש ב Web Services או בשימוש מוגבל בהם ומאידך ניתן לממש Web Services בארכיטקטורות שאינן SOA או ללא ארכיטקטורה בכלל.
תשתיות טכנולוגיות
ניתן לבנות ארכיטקטורה מכוונת שירותים על בסיס תשתיות קיימות שאינן ייעודיות ל SOA. עם זאת תשתיות ייעודיות מאפשרות במקרים רבים מימוש קל ומוצלח יותר של הארכיטקטורה בארגון.
ה-ESB הוא תשתית תווכה מרכזית באמצעותה מתבצעים תהליכי אינטגרציה בין שירותים או יישומים. בשונה מתשתיות כאלה שקדמו לו הוא מאפשר אינטגרציה מבוססת סטנדרטים ואינטגרציה בין שירותים.
מאגר מרכזי שבו מוגדרים השירותים בשלב הפיתוח או בשלב הייצור. המונח Service Registry מתייחס בעיקר לשלב הייצור. לצורך הפעלת שירותים ניתן לבצע תהליכי איתור קשירה (Binding) וביצוע המתבססים על ה Service Registry. במקרים רבים מבוסס ה Service Registry על סטנדרט UDDI.
כלים לניהול, ניטור ובקרה של שירותים בזמן ריצה. מטפלים בהיבטים כמו עמידה ב-SLA, ביצועים, איכות שירות ואבטחת מידע.
SOA ותהליכים עסקיים
אחת הדרכים העיקריות למימוש תועלות SOA היא שיפור התהליכים העסקיים. שיפור התהליכים העסקיים מושג בעיקר באמצעות המרכיבים הבאים:
גמישות תהליכים עסקיים
באמצעות ארכיטקטורה מוכוונת שירותים קל יותר לבצע שינויים בתהליכים העסקיים, כך שהארגון מגיב מהר יותר לשינויים עסקיים.
התאמה משופרת בין התהליכים העסקיים וייצוגם הממוחשב
מאפשר לאנשי העסקים להבין את הייצוג הממוחשב של התהליכים ואף לבצע שינויים במודל התהליכי.
חדשנות (Innovation)
מההתאמה המשופרת בין תהליכים עסקיים וייצוגם הממוחשב נגזרת האפשרות של אנשים שאינם מומחי מחשוב אך מכירים היטב את הצד העסקי של הארגון לעבור על תהליכים עסקיים באמצעים ממוחשבים ולהציע תהליכים חדשניים, העשויים להביא תועלות מהותיות לארגון.
ארכיטקטורות מוכוונות שירותים מאפשרות שיפור מחשוב תהליכים עסקיים באמצעות מספר גורמים:
תהליכים עסקיים וייצוגם הממוחשב מיוצגים בארכיטקטורה
שירות מהווה את היחידה האטומית המרכיבה את התהליך
ניתן לקבץ מספר שירותים לתהליך, אבל ניתן גם להתייחס לאוסף שירותים המרכיבים תהליך כאל שירות. יכולת זו מאפשרת להציג באופן פשוט יותר תהליכים כלל ארגוניים או תהליכים היוצאים מגבולות הארגון באמצעות אוסף תהליכים בעלי טווח קטן יותר המוצגים כל אחד כשירות.
סטנדרט WS-BPEL מבצע סטנדרטיזציה של שפת כתיבת התהליכים. אחד היתרונות של הסטנדרטיזציה, הוא יכולת למימוש תהליך בסביבות טכנולוגיות שונות שבהן ממומשים מנועי BPEL שונים המתממשקים זה לזה.
הטיפול בתהליכים עסקיים נעשה באמצעות מוצרי BPM לניהול תהליכים עסקיים ומוצרי BPA למידול וניתוח תהליכים עסקיים גם בתפיסות המונוליטיות בעולם המחשוב ולא רק בסביבות מוכוונות שירותים. המגמה היא שילוב BPM בארכיטקטורה מוכוונת שירותים באופן הדוק יותר.
SOA 2.0 הוא שילוב בין שתי ארכיטקטורות המשלימות זו את זו ארכיטקטורה מכוונת שירותים (SOA) וארכיטקטורה מוכוונת אירועים (EDA).ישנם יישומים ממוחשבים שאינם מתאימים לתפיסה של SOA. כך למשל יישומים ללא צימוד (Decoupled) השכיחים במערכת זמן אמת או במערכות רובוטיקה אינם מתאימים לארכיטקטורת SOA בה נדרש צימוד רפוי או צימוד הדוק. יישומים ללא צימוד מתאימים לארכיטקטורה מוכוונת אירועים. השימוש במושג זה נפוץ בעיקר על ידי אנליסטים של חברת Gartner Group ומומחים של חברת Oracle.
ארכיטקטורה מכוונת אירועים מתארת מצבים בהם התרחש אירוע המשנה מצב. התרחשות האירוע מביאה להפעלת רכיבי תוכנה באופן בלתי תלוי זה בזה. הארכיטקטורה משלימה את SOA, בכך שאירוע יכול להפעיל שירותים. במציאות ארגונית עשויים להתבצע תהליכים בהם שירותים מפעילים זה את זה באופן סדרתי (תפיסת SOA) או אירועים מורכבים בהם מופעלים מספר שירותים במקביל (כפי שמתרחש ב-EDA).
ישנה מחלוקת ביחס למקור של המונח, שיש הטוענים שנטבע על ידי אנליסטים של Gartner Group. שמות אחרים המתארים SOA 2.0 הם SOA2 ו-Advanced SOA בו השתמשו האנליסטים Yefim NatisוRoy Schulte. מבחינת בשלות טכנולוגית SOA 2.0 נמצא בשלבים מוקדמים. בתעשיית המחשוב קיימים חילוקי דעות ביחס לתועלות הצפויות ממנו וביחס לאפשרויות מימושו בארגונים.
WOA
WOA הוא שילוב של SOA ושל וב 2.0. המושג נטבע על ידי חברת האנליסטים Gartner Group. שילוב בין שתי תפיסות אלה הוא בהיבטים הבאים:
הרכבת יישומי SOA באמצעות טכנולוגיות וב 2.0
החזון של ארכיטקטורות מכוונות שירותים הוא הרכבת היישומים מאוסף שירותים. הרצוי ביותר הוא מצב בו איש עסקים המכיר היטב את הצד העסקי יהיה זה שירכיב את היישום ולא מומחה מחשוב. סביבת העבודה של מרכיב היישומים עשויה להיות במקרה זה סביבה של וב 2.0. המצב הנוכחי רחוק עדיין מהחזון. יצרני תוכנה נמצאים בתחילת הדרך בבניית פתרונות לחיבור בין שירותי SOA עם יישומי וב 2.0 במחשב הקצה שיהוו כלי בעזרתו ירכיב משתמש את היישומים מהשירותי ה-SOA.
שימוש בטכנולוגיות ווב 2.0 במימוש SOA
מימוש SOA מחייב טיפול גם בצד הצרכן. בצד הצרכן נעשה שימוש בטכנולוגיות תוכנה ביחידות קצה. המגמה היא לפתח יישומי אינטרנט עשירים (Rich Internet Applications). חלק מטכנולוגיות אלה הן טכנולוגיות המהוות חלק מווב 2.0. כך למשל AJAX המהווה מרכיב נפוץ במימוש יישומי וב 2.0 משמשת גם ארגונים בהקשר של מימוש ארכיטקטורה מכוונת שירותים. שימוש בשירותי רשת (Web Services) נפוץ גם ביישומי וב 2.0. טכנולוגיה חשובה המשרתת גם מימוש ארכיטקטורה מכוונת שירותים היא REST.
רעיונות דומים
בניית יישום מאוסף שירותים הוא אחד המרכיבים של SOA. בעולם הווב 2.0 נבנים Mashups שהם אוסף שירותים מהם מרכיב משתמש יישום ומפרסם אותו לשימוש חוזר בווב.
ערוצי הפצה
ארכיטקטורה מוכוונת שירותים עשויה לכלול ערוצי הפצה שונים המפעילים כולם את אותו שירות. האינטרנט, שהוא אחד מערוצי ההפצה החשובים, הוא גם הפלטפורמה התשתיתית של וב 2.0. בחלק מהמקרים וב 2.0 עצמו מהווה ערוץ הפצה לארגון המממש ארכיטקטורה מכוונת שירותים ומתאים לפנייה לדור הצעיר של לקוחותיו.
