Цоулоурис је дефинисао дистрибуиране системе као „системе у којима хардверске и/или софтверске компоненте које постоје у рачунарској мрежи комуницирају и координирају своје акције размјеном порука“.
Овај концепт је постао популаран последњих година због неколико фактора. Први фактор који је подстакао развој дистрибуираних система била је појава брзих локалних мрежа. Други важан фактор био је технолошки напредак у перформансама персоналних рачунара и развој софтвера за подршку дистрибуираним апликацијама. Дистрибуирани системи су повезани са концептом Веба и Интернета. Са еволуцијом Веба, и појавом нових области, интеракција, потреба и апликација, појављује се концепт Веб 2.0. Овај термин је сковао Тим О'Рајли 2004. године да се односи на другу генерацију у историји Веба засновану на корисничким заједницама и посебном спектру услуга, као што су друштвене мреже, блогови, викији или фолксономије, које подстичу сарадњу и брзу размена информација између корисника.
Прве архитектуре које се могу сматрати сервисно оријентисаним (СОА) биле су засноване на ЦОРБА (Архитектура Цоммон Објецт Рекуест Брокер Арцхитецтуре), која је деловала као слој апстракције за међусобно повезивање различитих елемената архитектуре и прављења услуга. Друге раније технологије биле су ДЦОМ (Дистрибутед Цомпонент Објецт Модел) или РПЦ (Ремоте Процедуре Протоцол). Са потребом да се ефикасно дизајнирају и имплементирају дистрибуирани системи на Вебу, јавља се неколико изазова, неки су усмерени на сам развој (перформансе, корисничко искуство, итд.) и други комплементарни, засновани на поновној употреби и компатибилности услуга. Из ових потреба произилазе Веб услуге, које обезбеђују стандардизоване механизме за међусобно повезивање различитих корисника са информационим серверима.
УСЛУЖНО ОРИЈЕНТОВАНЕ АРХИТЕКТУРЕ
Према СОА (Сервице Ориентед Арцхитецтуре) су софтверске архитектуре које дефинишу употребу услуга за подршку пословним захтевима, чији је циљ постизање што мањег могућег повезивања између софтверских агената. Услуга је јединица рада коју обавља пружалац услуге да би постигао крајњи резултат који жели потрошач услуге. И пружалац услуга и корисник услуга су улоге софтверских агената, а не власника софтвера. У општем смислу, сервисно оријентисана архитектура је софтверско решење намењено да омогући предузећу да организује и користи различите процесе. Са СОА-ом, софтверске апликације више нису масивни блокови функција и процеса. Уместо тога, ове апликације се састоје од склопљених модуларних услуга. Запамтите да је услуга једноставна софтверска функција (као што је отказивање ЦД-а). Може се покренути на захтев било ког система, без обзира на оперативни систем, платформу, програмски језик или географску локацију.
Оно што је револуционарно у СОА-и није сам концепт, који постоји већ дуго времена, већ чињеница да се може имплементирати преко ВВВ-а (Ворлд Виде Веб). На исти начин на који се веб странице учитавају на било којој платформи, веб услуге раде слично без обзира на платформу на којој су направљене
универзални стандарди.
Идеја СОА произилази директно из објектно оријентисаног програмирања, што сугерише однос између података и њихове обраде. Дакле, они формално дефинишу услуге кроз интерфејсе који су независни од основне платформе и програмског језика. Ови интерфејси крију особености њихове имплементације, што их чини независним од програмер и програмски језик. Кроз ове архитектуре, могуће је дизајнирати и имплементирати високо скалабилне системе који одражавају пословну логику и истовремено олакшавају интеракцију између различитих власничких система или система трећих страна. Разлог зашто желимо да неко други ради посао уместо нас је тај што су стручњаци. Коришћење услуге је обично јефтиније и ефикасније него да то урадите сами. Дакле, већина нас разуме да не можемо бити стручњаци за све. Исто правило се може применити на изградњу софтверских система.
Интерфејси су веома важни, ако нису добро дефинисани или не раде, систем не ради. Интегрисање више интерфејса је скупо и такође повећава потенцијал за грешке у дистрибуираним апликацијама. Удаљени интерфејси су најспорији део већине дистрибуираних апликација. Уз све ово, уместо изградње нових интерфејса за сваку апликацију, има смисла поново користити генеричке интерфејсе за све апликације.
Дакле, пошто имамо само неколико доступних генеричких интерфејса, морамо укључити семантику специфичну за апликацију у поруке. Можемо да шаљемо било коју врсту поруке преко наших интерфејса, али постоје нека правила која се морају поштовати да кажемо да је архитектура оријентисана на услуге.
– Прво, поруке морају бити описне, а не поучне, јер је провајдер сервиса одговоран за решавање проблема. На пример, то би било слично ситуацији да одете у ресторан и кажете конобару шта желите да попијете и шта волите, али не би требало да објашњавамо кувару како да спрема ваша јела, корак по корак.
‐ Друго, провајдери услуга неће моћи да разумеју ваш захтев ако њихове поруке нису написане у формату, структури и речнику разумљивом за све укључене. Дакле, ограничавање речника и структуре порука је а
неопходна за ефикасну комуникацију. Што је порука ужа, то је лакше разумети.
- Треће, могућност продужења је од виталног значаја. Свет је место које се стално мења, као и окружење у коме живи софтвер. Ове промене захтевају одговарајуће промене у системском софтверу, потрошачима услуга, провајдера и порука које размењују. Ако поруке нису прошириве, потрошачи и провајдери су закључани на одређену верзију услуге. Ограничење и проширивост су дубоко повезани, потребно вам је обоје, а повећање једног значи смањење другог. Идеално је постићи исправан баланс.
– Четврто, СОА мора имати механизам који омогућава потрошачу да открије пружаоца услуге у контексту услуге коју потрошач тражи. Механизам треба да буде флексибилан, а не централизовани регистар.
- Пето, услуга без држављанства: Свака порука коју потрошач пошаље добављачу мора да садржи све информације неопходне да би је провајдер обрадио. Ово ограничење чини провајдера услуга скалабилнијим, пошто провајдер не мора да чува информације о стању између захтева. Ово се може назвати „услугом масовне производње“ јер се сваки захтев може генерисати. Ово ограничење такође пружа већу видљивост, јер сваки софтвер за праћење може независно да прегледа захтев и извуче његову намеру. Ово такође омогућава лак опоравак од делимичних кварова јер нема међустања, што услугу чини поузданијом.
- Шесто, идемпотентни захтеви (без измена): дупли захтеви које је примио софтверски агент имају исти ефекат као и један захтев. Овај захтев омогућава добављачима и потрошачима да повећају укупну поузданост сервис, једноставно понављајући захтев ако је било квара.
Дакле, можемо рећи да СОА није алат, већ скуп стандарда за изградњу нових апликација, динамичнијих и мање зависних. СОА олакшава приступ пословној логици и информацијама у више сервиса на систематичан начин, а такође може оркестрирати више удаљених услуга да би се саставио један. већина дефиниције идентификују употребу Веб услуга, што ћемо видети у следећем поглављу, у имплементацији сервисно оријентисане архитектуре. Међутим, може се имплементирати коришћењем било које друге технологије засноване на услугама.