Кулуріс визначив розподілені системи як «системи, в яких апаратні та/або програмні компоненти, існуючі в комп’ютерній мережі, спілкуються та координують свої дії шляхом обміну повідомленнями».
Ця концепція стала популярною в останні роки через кілька факторів. Першим фактором, який сприяв розвитку розподілених систем, стала поява високошвидкісних локальних мереж. Іншим важливим фактором був технологічний прогрес у продуктивності персональних комп'ютерів і розробка програмного забезпечення для підтримки розподілених програм. Розподілені системи пов'язані з концепцією Інтернету та Інтернету. З еволюцією Інтернету та появою нових сфер, взаємодій, потреб і застосувань з’являється концепція Веб 2.0. Цей термін був введений Тімом О'Райлі в 2004 році для позначення другого покоління в історії Інтернету, заснованого на спільнотах користувачів і спеціальному наборі послуг, таких як соціальні мережі, блоги, вікі або фольксономія, які заохочують співпрацю та швидку роботу. обмін інформацією між користувачами.
Перші архітектури, які можна вважати сервіс-орієнтованими (SOA), базувалися на CORBA (Common Object Request Broker Architecture), яка діяла як рівень абстракції для взаємозв’язку різних елементів архітектури та створення служб. Іншими попередніми технологіями були DCOM (модель розподілених компонентних об’єктів) або RPC (протокол віддаленої процедури). У зв’язку з необхідністю ефективного проектування та впровадження розподілених систем в Інтернеті виникає кілька проблем, деякі зосереджені на самій розробці (продуктивність, досвід користувача тощо), а інші – додаткові, засновані на повторному використанні та сумісності послуг. З цих потреб виникають веб-сервіси, які забезпечують стандартизовані механізми для взаємозв’язку різних користувачів з інформаційними серверами.
СЕРВІСНО-ОРІЄНТОВАНА АРХІТЕКТУРА
Відповідно до SOA (сервісно-орієнтована архітектура) — це архітектури програмного забезпечення, які визначають використання сервісів для підтримки бізнес-вимог, метою яких є досягнення найменшого можливого зв’язку між програмними агентами. Послуга — це одиниця роботи, яку виконує постачальник послуг для досягнення кінцевого результату, бажаного споживачем послуг. І постачальник послуг, і споживач послуг — це ролі, які виконують програмні агенти, а не власники програмного забезпечення. У загальному розумінні сервіс-орієнтована архітектура — це програмне рішення, призначене для того, щоб підприємство організувало та використовувало різні процеси. З SOA програмні додатки більше не є масивними блоками функцій і процесів. Натомість ці програми складаються із зібраних модульних служб. Пам’ятайте, що послуга – це проста програмна функція (наприклад, скасування компакт-диска). Його можна запускати на вимогу будь-якою системою, незалежно від операційної системи, платформи, мови програмування чи географічного розташування.
Революційним у SOA є не сама концепція, яка існує вже давно, а те, що її можна реалізувати через WWW (Всесвітню павутину). Подібно до того, як веб-сторінки завантажуються на будь-якій платформі, веб-служби працюють однаково незалежно від платформи, на якій вони створені
універсальні стандарти.
Ідея SOA випливає безпосередньо з об'єктно-орієнтованого програмування, яке передбачає зв'язок між даними та їх обробкою. Таким чином, вони формально визначають служби через інтерфейси, які не залежать від базової платформи та мови програмування. Ці інтерфейси приховують особливості їх реалізації, що робить їх незалежними від розробник і мова програмування. За допомогою цих архітектур можна розробляти та впроваджувати високомасштабовані системи, які відображають бізнес-логіку та водночас полегшують взаємодію між різними пропрієтарними або сторонніми системами. Причина, чому ми хочемо, щоб хтось інший виконав роботу за нас, полягає в тому, що вони є експертами. Використання послуги зазвичай дешевше та ефективніше, ніж робити це самостійно. Тому більшість із нас розуміє, що ми не можемо бути експертами в усьому. Це ж правило можна застосувати до створення програмних систем.
Інтерфейси дуже важливі, якщо вони не чітко визначені або не працюють, система не працює. Інтеграція більшої кількості інтерфейсів коштує дорого, а також збільшує ймовірність помилок у розподілених програмах. Віддалені інтерфейси є найповільнішою частиною більшості розподілених програм. З огляду на все це, замість того, щоб створювати нові інтерфейси для кожної програми, має сенс повторно використовувати загальні інтерфейси для всіх програм.
Отже, оскільки ми маємо лише кілька доступних загальних інтерфейсів, ми повинні включити до повідомлень семантику, специфічну для програми. Ми можемо надсилати будь-які повідомлення через наші інтерфейси, але є деякі правила, яких слід дотримуватися, щоб сказати, що архітектура є сервіс-орієнтованою.
– По-перше, повідомлення мають бути описовими, а не повчальними, оскільки відповідальність за вирішення проблеми несе постачальник послуг. Наприклад, це було б схоже на ситуацію, коли ви йдете в ресторан і розповідаєте офіціанту, що ви б хотіли випити, і свої вподобання, але ми не повинні пояснювати кухареві, як крок за кроком готувати ваші страви.
‐ По-друге, постачальники послуг не зможуть зрозуміти ваш запит, якщо їхні повідомлення не будуть написані у форматі, структурі та словниковому запасі, зрозумілому всім учасникам. Таким чином, обмеження словникового запасу та структури повідомлень є а
необхідні для ефективного спілкування. Чим вужче повідомлення, тим легше його зрозуміти.
– По-третє, життєво важлива можливість пролонгацій. Світ постійно змінюється, як і середовище, в якому живе програмне забезпечення. Ці зміни потребують відповідних змін у системному програмному забезпеченні, споживачах послуг, постачальників і повідомлень, якими вони обмінюються. Якщо повідомлення не розширюються, споживачі та постачальники прив’язані до певної версії служби. Обмеження та розширюваність глибоко пов’язані, вам потрібні обидва, і збільшення одного означає зменшення іншого. Ідеал - досягти правильного балансу.
– По-четверте, SOA повинен мати механізм, який дозволяє споживачеві знайти постачальника послуг у контексті послуги, яку шукає споживач. Механізм має бути гнучким, а не централізованим реєстром.
- По-п'яте, послуга без громадянства: кожне повідомлення, яке споживач надсилає постачальнику, має містити всю інформацію, необхідну постачальнику для його обробки. Це обмеження робить постачальника послуг більш масштабованим, оскільки постачальнику не потрібно зберігати інформацію про стан між запитами. Це можна назвати «сервісом масового виробництва», оскільки кожен запит можна обробляти узагальнено. Це обмеження також забезпечує кращу видимість, оскільки будь-яке програмне забезпечення для моніторингу може самостійно перевіряти запит і виявляти його наміри. Це також дозволяє легко відновлюватися після часткових збоїв, оскільки немає проміжних станів, що робить службу більш надійною.
- По-шосте, ідемпотентні запити (без змін): повторювані запити, отримані програмним агентом, мають той самий ефект, що й один запит. Ця вимога дозволяє постачальникам і споживачам підвищити загальну надійність обслуговування, просто повторюючи запит, якщо стався якийсь збій.
Тож можна сказати, що SOA — це не інструмент, а набір стандартів для створення нових додатків, більш динамічних і менш залежних. SOA полегшує систематичний доступ до бізнес-логіки та інформації в кількох службах, а також може керувати кількома віддаленими службами для створення однієї. більшість визначення ідентифікують використання веб-сервісів, які ми побачимо в наступному розділі, у реалізації сервіс-орієнтованої архітектури. Однак його можна реалізувати за допомогою будь-якої іншої технології на основі сервісу.