Ориентираната към услуги архитектура (SOA) е архитектурен модел в дизайна на компютърен софтуер, при който компонентите на приложението предоставят услуги на други компоненти чрез комуникационен протокол, обикновено през мрежа. Принципите на ориентация към услугата са независими от всеки продукт, доставчик или технология.
SOA просто улеснява работата на софтуерните компоненти в различни мрежи помежду си.
Уеб услугите, които са изградени според архитектурата на SOA, обикновено правят уеб услугата по-независима. Самите уеб услуги могат да обменят данни помежду си и поради основните принципи, на които са създадени, те не се нуждаят от някакъв вид човешко взаимодействие и също така не се нуждаят от никакви модификации на кода. Той гарантира, че уеб услугите в мрежата могат да си взаимодействат безпроблемно.
SOA се основава на някои ключови принципи, които са споменати по-долу
- Стандартизиран договор за услуга - услугите спазват описанието на услугата. Услугата трябва да има някакво описание, което описва за какво става въпрос. Това улеснява клиентските приложения да разберат какво прави услугата.
- Разхлабено свързване - По-малко зависимост един от друг. Това е една от основните характеристики на уеб услугите, която просто заявява, че трябва да има възможно най-малка зависимост между уеб услугите и клиента, който се позовава на уеб услугата. Така че, ако функционалността на услугата се промени по всяко време, тя не трябва да нарушава клиентското приложение или да го спира да работи.
- Абстракция на услуги - Услугите скриват логиката, която капсулират, от външния свят. Услугата не трябва да излага как изпълнява своята функционалност; трябва просто да каже на клиентското приложение какво прави, а не как го прави.
- Многократна употреба на услугата - логиката е разделена на услуги с цел максимизиране на повторното използване. Във всяка компания за разработчици повторното използване е голяма тема, защото очевидно човек не би искал да отделя време и усилия за изграждане на един и същ код отново и отново в множество приложения, които ги изискват. Следователно, след като кодът за уеб услуга бъде написан, той трябва да има способността да работи с различни видове приложения.
- Автономност на услугата - услугите трябва да имат контрол над логиката, която капсулират. Услугата знае всичко за това каква функционалност предлага и следователно трябва също така да има пълен контрол над кода, който съдържа.
- Гражданство без гражданство - В идеалния случай услугите трябва да са без гражданство. Това означава, че услугите не трябва да задържат информация от една държава в друга. Това ще трябва да се направи или от клиентското приложение. Пример може да бъде поръчка, направена в сайт за пазаруване. Сега можете да имате уеб услуга, която ви дава цената на даден артикул. Но ако артикулите се добавят към пазарска количка и уеб страницата се придвижва до страницата, на която извършвате плащането, отговорността на цената на артикула, който ще бъде прехвърлен на страницата за плащане, не трябва да се поема от уеб услугата. Вместо това трябва да се направи от уеб приложението.
- Откриваемост на услугата - Услугите могат да бъдат открити (обикновено в регистър на услугата). Вече видяхме това в концепцията за UDDI, която изпълнява регистър, който може да съдържа информация за уеб услугата.
- Композивност на услугите - услугите разбиват големите проблеми на малки проблеми. Никога не трябва да се вгражда цялата функционалност на дадено приложение в една единствена услуга, а вместо това да се раздели услугата на модули, всеки с отделна бизнес функционалност.
- Оперативна съвместимост на услугите - Услугите трябва да използват стандарти, които позволяват на различни абонати да използват услугата. В уеб услугите се използват стандарти като XML и комуникация през HTTP, за да се гарантира, че отговаря на този принцип.