Сервісно-орієнтована архітектура (SOA) - це архітектурний шаблон у розробці програмного забезпечення комп’ютера, при якому компоненти додатків надають послуги іншим компонентам через протокол зв'язку, як правило, через мережу. Принципи орієнтації на послуги не залежать від будь-якого товару, постачальника чи технології.
SOA просто полегшує роботу програмних компонентів через різні мережі між собою.
Веб-служби, побудовані відповідно до архітектури SOA, як правило, роблять веб-сервіс більш незалежним. Самі веб-служби можуть обмінюватися даними між собою, і завдяки основним принципам, на яких вони створені, їм не потрібна будь-яка людська взаємодія, а також не потрібні будь-які модифікації коду. Це гарантує, що веб-служби в мережі можуть безперешкодно взаємодіяти між собою.
SOA базується на деяких ключових принципах, які згадані нижче
- Стандартизований контракт на надання послуг - послуги відповідають опису послуг. Послуга повинна мати якийсь опис, який описує, про що йдеться в службі. Це полегшує клієнтським програмам розуміння того, що робить служба.
- Слабке зчеплення - Менша залежність один від одного. Це одна з основних характеристик веб-служб, яка просто стверджує, що між веб-службами та клієнтом, що викликає веб-службу, повинно бути якомога менше залежності. Отже, якщо функціональність служби змінюється в будь-який момент часу, це не повинно зламати клієнтську програму або зупинити її роботу.
- Абстракція послуг - служби приховують логіку, яку вони інкапсулюють, від зовнішнього світу. Послуга не повинна розкривати, як вона виконує свою функціональність; він повинен просто повідомити клієнтському додатку про те, що він робить, а не про те, як він це робить.
- Повторне використання послуг - логіка поділяється на служби з метою максимізації повторного використання. У будь-якій розробницькій компанії повторне використання є великою темою, оскільки очевидно, що не хочеться витрачати час і зусилля на створення того самого коду знову і знову для багатьох додатків, які потребують їх. Отже, як тільки код веб-служби написаний, він повинен мати можливість працювати з різними типами програм.
- Автономія служби - служби повинні контролювати логіку, яку вони інкапсулюють. Послуга знає все про те, яку функціональність вона пропонує, а отже, вона також повинна мати повний контроль над кодом, який вона містить.
- Безгромадянство - в ідеалі, послуги повинні бути без громадянства. Це означає, що служби не повинні утримувати інформацію від однієї держави до іншої. Це потрібно було б зробити з будь-якої програми клієнта. Прикладом може бути замовлення, розміщене на торговому сайті. Тепер ви можете мати веб-сервіс, який визначає ціну певного товару. Але якщо товари додаються до кошика для покупок, а веб-сторінка переходить до сторінки, де ви здійснюєте платіж, веб-служба не повинна нести відповідальність за ціну товару, який буде перенесено на сторінку платежу. Натомість це має робити веб-додаток.
- Виявлення послуг - Служби можна виявити (зазвичай у реєстрі служб). Ми вже бачили це в концепції UDDI, який створює реєстр, який може містити інформацію про веб-службу.
- Складність послуг - сервіси розбивають великі проблеми на невеликі. Ніколи не слід вбудовувати всю функціональність програми в одну службу, а натомість розбивати службу на модулі, кожен з яких має окремий бізнес-функціонал.
- Сумісність послуг - Служби повинні використовувати стандарти, які дозволяють послугам користуватися різним абонентам. У веб-сервісах використовуються стандарти, як XML та зв'язок через HTTP, щоб переконатися, що вони відповідають цьому принципу.