Кулурис дефинира разпределените системи като „системи, в които хардуерни и/или софтуерни компоненти, съществуващи в компютърна мрежа, комуникират и координират своите действия чрез обмен на съобщения“.
Тази концепция стана популярна през последните години поради няколко фактора. Първият фактор, който насърчи развитието на разпределени системи, беше появата на високоскоростни локални мрежи. Друг важен фактор беше технологичният напредък в производителността на персоналните компютри и разработването на софтуер за поддръжка на разпределени приложения. Разпределените системи са свързани с концепцията за мрежата и интернет. С развитието на мрежата и появата на нови области, взаимодействия, нужди и приложения се появява концепцията за уеб 2.0. Този термин е измислен от Тим О'Райли през 2004 г., за да обозначи второ поколение в историята на мрежата, базирано на потребителски общности и специална гама от услуги, като социални мрежи, блогове, уикита или фолксономии, които насърчават сътрудничеството и бързото обмен на информация между потребителите.
Първите архитектури, които могат да се считат за ориентирани към услуги (SOA), са базирани на CORBA (Common Object Request Broker Architecture), която действа като абстракционен слой за взаимно свързване на различните елементи на архитектурата и изграждане на услуги. Други по-ранни технологии бяха DCOM (Distributed Component Object Model) или RPC (Remote Procedure Protocol). С необходимостта от ефективно проектиране и внедряване на разпределени системи в мрежата възникват няколко предизвикателства, някои фокусирани върху самото развитие (производителност, потребителско изживяване и т.н.), а други допълващи се, базирани на повторната употреба и съвместимостта на услугите. От тези нужди възникват уеб услуги, които предоставят стандартизирани механизми за свързване на различни потребители с информационни сървъри.
АРХИТЕКТУРИ, ОРИЕНТИРАНИ КЪМ УСЛУГИТЕ
Според SOA (Service Oriented Architecture) са софтуерни архитектури, които определят използването на услуги за поддържане на бизнес изисквания, чиято цел е да се постигне възможно най-малкото свързване между софтуерните агенти. Услугата е единица работа, извършена от доставчик на услуга за постигане на краен резултат, желан от потребителя на услугата. И доставчикът на услуга, и потребителят на услугата са роли, изпълнявани от софтуерни агенти, а не от собственици на софтуер. В общ смисъл, ориентираната към услугата архитектура е софтуерно решение, предназначено да позволи на предприятието да организира и използва различни процеси. Със SOA софтуерните приложения вече не са масивни блокове от функции и процеси. Вместо това тези приложения са съставени от сглобени модулни услуги. Не забравяйте, че услугата е проста софтуерна функция (като анулиране на компактдиск). Може да се изпълнява при поискване от всяка система, независимо от операционната система, платформата, езика за програмиране или географското местоположение.
Това, което е революционно при SOA, не е самата концепция, която съществува от дълго време, а фактът, че може да се внедри в WWW (World Wide Web). По същия начин, по който уеб страниците се зареждат на всяка платформа, уеб услугите работят по подобен начин, независимо от платформата, използвана от тях
универсални стандарти.
Идеята за SOA произтича директно от обектно-ориентираното програмиране, което предполага връзка между данните и тяхната обработка. По този начин те формално дефинират услуги чрез интерфейси, които са независими от основната платформа и езика за програмиране. Тези интерфейси крият особеностите на тяхната реализация, което ги прави независими от програмист и език за програмиране. Чрез тези архитектури е възможно да се проектират и внедрят силно мащабируеми системи, които отразяват бизнес логиката и в същото време улесняват взаимодействието между различни собствени системи или системи на трети страни. Причината да искаме някой друг да свърши работата вместо нас е, че те са експерти. Използването на услуга обикновено е по-евтино и по-ефективно, отколкото да го направите сами. Така че повечето от нас разбират, че не могат да бъдат експерти във всичко. Същото правило може да се приложи за изграждане на софтуерни системи.
Интерфейсите са много важни, ако не са добре дефинирани или не работят, системата не работи. Интегрирането на повече интерфейси е скъпо и също така увеличава потенциала за грешки в разпределените приложения. Отдалечените интерфейси са най-бавната част от повечето разпределени приложения. С всичко това, вместо да се изграждат нови интерфейси за всяко приложение, има повече смисъл да се използват повторно общи интерфейси за всички приложения.
Така че, тъй като имаме само няколко налични общи интерфейса, трябва да включим специфична за приложението семантика в съобщенията. Можем да изпратим всякакъв вид съобщение чрез нашите интерфейси, но има някои правила, които трябва да се следват, за да се каже, че една архитектура е ориентирана към услуги.
– Първо, съобщенията трябва да са описателни, а не инструктивни, тъй като доставчикът на услугата носи отговорност за разрешаването на проблема. Например, би било подобно на ситуацията да отидете в ресторант и да кажете на сервитьора какво искате да пиете и вашите предпочитания, но не трябва да обясняваме на готвача как да приготви вашите ястия, стъпка по стъпка.
‐ Второ, доставчиците на услуги няма да могат да разберат вашата заявка, ако техните съобщения не са написани във формат, структура и речник, разбираеми за всички участници. По този начин ограничаването на речника и структурата на съобщенията е a
необходими за ефективна комуникация. Колкото по-тясно е посланието, толкова по-лесно за разбиране.
- На трето място, възможността за разширения е от жизненоважно значение. Светът е постоянно променящо се място, както и средата, в която живее софтуерът. Тези промени изискват съответните промени в системния софтуер, потребителите на услугите, доставчиците и съобщенията, които обменят. Ако съобщенията не са разширими, потребителите и доставчиците са заключени към конкретна версия на услугата. Ограничението и разширяемостта са дълбоко свързани, имате нужда и от двете, а увеличаването на едното означава намаляване на другото. Идеалното е да се постигне правилен баланс.
– Четвърто, SOA трябва да има механизъм, който позволява на потребителя да открие доставчик на услуга в контекста на услуга, търсена от потребителя. Механизмът трябва да е гъвкав, а не централизиран регистър.
- Пето, услуга без гражданство: Всяко съобщение, което потребител изпраща до доставчик, трябва да съдържа цялата информация, необходима на доставчика, за да го обработи. Това ограничение прави доставчика на услуги по-мащабируем, тъй като доставчикът не трябва да съхранява информация за състоянието между заявките. Това може да се нарече „услуга за масово производство“, тъй като всяка заявка може да се обработва общо. Това ограничение също така осигурява по-голяма видимост, тъй като всеки софтуер за наблюдение може независимо да инспектира заявка и да извлече нейното намерение. Това също позволява лесно възстановяване от частични повреди, тъй като няма междинни състояния, което прави услугата по-надеждна.
- Шесто, идемпотентни заявки (без промяна): дублирани заявки, получени от софтуерен агент, имат същия ефект като единична заявка. Това изискване позволява на доставчиците и потребителите да повишат цялостната надеждност на услуга, като просто повтаря заявката, ако има някаква грешка.
Така че можем да кажем, че SOA не е инструмент, а набор от стандарти за изграждане на нови приложения, по-динамични и по-малко зависими. SOA улеснява достъпа до бизнес логика и информация в множество услуги по систематичен начин и може също така да организира множество отдалечени услуги, за да състави една единствена. повечето от дефинициите идентифицират използването на уеб услуги, което ще видим в следващата глава, при внедряването на ориентирана към услугата архитектура. Въпреки това, той може да бъде реализиран с помощта на всяка друга технология, базирана на услуги.