Услужно ориентирана архитектура

Сервисно ориентирана архитектура (англиски: SOA) е софтверска архитектура каде функционалноста е групирана околу бизнис процеси и спакувана како интероперабилни сервиси. SOA исто така опишува IT инфраструктура која овозможува на различни апликации меѓусебно да ги разменуваат податоците при нивното учество во бизнис процесите. Целта е loose coupling на сервисите со оперативните системи, програмските јазици и останатите технологии кои се основа на апликациите.

SOA ги дели функциите на посебни единици (сервиси) кои стануваат достапни преку мрежа со цел тие да можат да бидат комбинирани и употребени во создавање на бизнис апликации. Овие сервиси меѓусебно комуницираат со пренесување на податоци од еден сервис на друг, или пак координирајќи ја активноста на два или повеќе сервиси. На концептот на SOA најчесто се гледа како на надградба на постарите концепти како дистрибуирана обработка и модуларно програмирање.

SOA апликациите се градат од софтверски сервиси. Всушност, сервисите се неповрзани единици на функционалност кои во себе не содржат меѓусебно повикување. Тие извршуваат функции кои луѓето ги препознаваат како сервиси, како пополнување на online апликација за сметка, следење на online банковен извештај, или пак online букирање на авионски билети. Наместо вметнување на меѓусебно повикување во изворниот код на сервисите, се дефинираат протоколи кои дефинираат како еден или повеќе сервиси ќе комуницираат меѓу себе. Понатаму, оваа архитектура се потпира на експерт за бизнис процесот, кој ги поврзува и подредува сервисите за да можат да одговорат на новите или постоечките барања. Овој процес е познат како оркестрација.

Во однос на раните обиди за повеќекратна употреба на софтверот преку модуларност на функции или преку употреба на претходно дефинирани групи на функции познати како класи, атомичните објекти во SOA се 100-1000 пати поголеми и се поврзани од дизајнерот на апликацијата со користење на оркестрација. Во процесот на оркестрација релативно големи делови на софтверска функционалност (сервиси) се поврзуваат на не-хиерархиски начин (спротивно на хиерархија на класи) со помош на специјална софтверска алатка. Таа алатка содржи исцрпна список на сите сервиси, нивните одлики и начини за запишување на опциите на дизајнерот со кои тој може да управува, софтверскиот систем може да ги разбере и употреби во run-time.

Во основа на сето ова се metadata податоците кои се доволни да ги опишат не само одликите на тој сервис, туку и податоците што управуваат со нив. Во SOA широко се користи XML за создавање на податоци кои се поставени во детален, исцрпен описен контејнер. Аналогно на тоа, самите сервиси се опишани со WSDL (Web Services Description Language), а комуникациските протоколи со SOAP (Simple Object Access Protocol). Во моментот е отворено прашање дали ови описни јазици се најпогодни за дадената работа и дали и во иднина ќе останат најупотребувани. Она што е сигурно е дека SOA се потполно зависни од податоците и сервисите кои се опишани со користење на metadata, кои пак треба да исполнуваат два критериума. Тие мора да бидат во форма која софтверскиот систем може динамички да ја конфигурира за да одржи кохерентност и интегритет, и во форма која дизајнерот може да ја разбере и користи.

Целта на SOA е да овозможи поставување во низа на релативно големи делови од функционалности така што формираат апликација речиси целосно изградена изградена од постоечки софтверски сервиси. Колку се поголеми тие делови, толку се поретки точките во посредникот каде се бара да се примени некој даден сет на функционалност. Меѓутоа, со многу големи делови на функционалности системот може да има мала грануларност (степен до кој системот има одделни компоненти, поголема грануларност – пофлексибилен u1089 систем) и да не биде соодветен за повторна употреба. Секој посредник носи со себе одредена количина на трошоци за обработка, па поради тоа при избор на грануларноста на сервисите треба да се поведе сметка за учинокот. Голема предност на SOA е тоа што крајните трошоци за создавање на n-тата апликација се нула, бидејќи целиот потребен софтвер веќе постои, а потребна е само оркестрација за да се произведе нова апликација.

Клучот е во тоа што помеѓу деловите нема интеракција специфицирана во самите делови. Наместо тоа интеракцијата на сервисите се специфицира од луѓето за секој посебен случај, во зависност од новопојавените барања. Одтука произлегува потребата сервисите да бидат доста поголеми единици на функционалност отколку традиционалните функции или класи. Во спротивно, комплексноста на илјадници грануларни објекти може да го збуни дизајнерот на апликацијата. Самите сервиси се развиваат со примена на традиционални јазици како Java, C#, C++, C или COBOL.

SOA како архитектура е услужно ориентирана како нејзин основен принцип. Услугата е претставена со едноставен посредник кој ја апстрахира сложеноста, корисниците можат да пристапат до услугите без знаење како истата е имплементирана.

Барања

Со цел ефикасно да се користи SOA мора да се исполнат следните барања:

Интероперабилност помеѓу различни системи и програмски јазици што овозможува основа за интеграција помеѓу апликации на различни платформи преку комуникациски протокол. Еден пример за таквата комуникација зависи од концептот на пораки. Користење на пораки преку дефинирани канали за пораки ја намалува комплексноста на апликација, така овозможувајќи им на развивачот на апликацијата да се фокусира на вистинската примена и функционалноста наместо на сложени потреби на комуникацискиот протокол.
Желба да се создаде обединување на ресурси. Воспоставување и одржување на проток на податоци до обединет податочен систем. Ова им овозможува на новата функционалност да повикува заеднички бизнис формат за секој податочен елемент.

Loose coupling со SOA

Услужно-ориентираната архитектура има за цел да постигне loose coupling на софтверски агенти кои работат интерактивно. Сервисот или услугата е работна единица која е создадена од услужникот на услуга со цел да ги обезбеди саканите резултати за корисникот на услугата. И услужникот и корисникот во случајот на SOA се софтверски агенти кои функционираат од име на своите сопственици.

Користењето на услуги кај SOA значи „раздвојување на интереси“, при што секоја услуга значи постоење на експерт кој ја завршува работата за другите. Ова претставува основен принцип на софтверското инжинерство.

SOA постигнува loose coupling на софтверски агенти кои дејствуваат интерактивно со користење на две архитектурни ограничувања:

Малo множество на едноставни и сеприсутни интерфејси. За интерфејсите се кодира само генеричката семантика, а тие треба да бидат достапни за сите услужници и корисници.
Основна единица за комуникација е описна порака ограничена со проширлива шема доставена преку интерфејсот. Одредување на системското однесување преку пораки нема или е минимално. Шемата ја ограничува синтаксата и структурата на пораките. Проширливата шема дозволува воведување на нови верзии на сервиси без нарушување на постоечките сервиси.

Интерфејсот треба да го пропише однесувањето на системот, а многу е тешко да се имплементира коректно за различни платформи и јазици. Оддалечените посредници се најспориот дел на најголем број на дистрибуирани апликации. Наместо градење на нови посредници за секоја апликација може да се искористат неколку генерички посредници за сите апликации. Бидејќи постојат само неколку генерички интерфејси, специфичната семантика на апликациите мора да се изрази во пораки.

При создавање на посредник за еден SOA сервис треба да се исполнат неколку правила:

Пораката мора да биде описна, а не инструктивна
Пораката треба да е напишана во формат, структура и терминологија кои се разбирливи за сите страни
Пораките мора да се екстензибилни за да ги поддржат промените кои би дошле во иднина
SOA мора да има механизам за корисникот да може да пронајде соодветен сервис услужник во контекст на услугите што ги бара

Дополнителни ограничувања

Со цел да се подобри адаптибилноста на зголемени барања, работата на сервисите и доверливоста треба да се имаат предвид следните ограничувања:

Stateless сервис не ја чува состојбата за она што се случувало претходно. Во секоја порака која се испраќа до услужникот треба да се содржани сите потребни информации за обработка на пораката. Ова ја зголемува адаптибилноста на сервисот бидејќи не мора да се чуваат состојбите измеѓу барањата. Исто така, ова ограничување ја подобрува видливоста бидејќи секој софтвер за мониторинг може да испита едно поединечно барање и да ја разбере неговата намера. Не постојат меѓусостојби за кои треба да се води сметка, па поради тоа враќањето во нормална состојба по делумен пад е релативно лесно, што го прави системот подоверлив.

Stateful сервис ја чува состојбата за она што се случувало претходно. Во одредени ситуации е потребно да се чува информација за она што претходно се случувало. Таков случај е на пример воспоставување на сесија помеѓу корисникот и услужникот која обично се воспоставува поради ефикасност. Друг случај е обезбедување на персонализиран сервис кога корисникот и услужникот делат ист consumer-specific контекст, кој е или вклучен или референциран во пораките кои се разменуваат помеѓу корисникот и услужникот. Негативен аспект на ова ограничување е што може да ја намали глобалната адаптабилност на сервис услужникот, бидејќи треба да го памети контекстот на секој корисник. Исто така ја зголемува поврзаноста на сервис услужникот и корисникот, што го прави потешко менувањето на сервис услужникот.

Web сервиси во SOA

Web сервисите може да се применат во услужно-ориентираните архитектури. Web сервисите се главно фокусирани на подготвување на функционални градбени блокови достапни преку стандардните Интернет протоколи кои се независни од платформите и програмските јазици. Овие сервиси можат да бидат нови апликации или само придодадени на веќе постоечки системи за да станат достапни преку Интернет мрежата.

Секој градбен блок на SOA може да игра една или повеќе од следните улоги:

Сервис услужник - создава Web сервис и по можност го објавува неговиот посредник и пристапна информација во регистерот на сервиси. Секој услужник мора да одлучи кој сервис ќе го објави, како да направи рамнотежа помеѓу сигурноста и лесната достапност, како да ја одреди цената на сервисот, или ако е бесплатен, како да го искористи за друга вредност. Исто така, услужникот треба да одлучи во која категорија на сервис ќе биде запишан сервисот и кој тип на партнерски договори за размена се потребни за користење на сервисот.
Сервис брокер - познат како регистар на сервиси, треба да ги направи достапни интерфејсите на Web сервисот и информациите за пристап до секој потенцијален барател на сервис. Јавните брокери се достапни преку интернет, додека приватни посредници се достапни само на ограничена група (на пример на кориници на компаниски интранет). Понатаму, количината на понудените информации може да биде променлива. Некои брокери даваат обемни листинзи, а некои пак поограничена количина со висока доверба, некои покриваат широка лепеза на сервиси, а некои пак се ограничуваат на индустријата, а некои посредници се повикуваат и на други посредници. Во зависност од бизнис моделот посредникот може да проба да го максимизира барањето за пребарување, бројот или точноста на листинзите. За објавување и наоѓање на информации за Web сервисите постои спецификација Universal Description Discovery and Integration (UDDI). Освен оваа спецификација постојат и ebXML (Electronic Business using eXtensible Markup Language) или Metadata Registry (MDR) стандард заснован на ISO/IEC 11179.
Корисник на сервисот - т.н Web сервис клиент ги лоцира влезовите во регистарот на посредникот, со користење на различни find операции, а потоа се поврзува на сервис услужникот со цел да повика некој од неговите Web сервиси.