Ориентираната към услуги архитектура () е начин за асемблиране на софтуерни приложения, инженеринг и бизнес процеси чрез свързване на софтуерни услуги. Програмистите разработват тези услуги използвайки традиционни езици като Java, C, C++, C#, Visual Basic, COBOL или PHP. Ориентираната към услуги архитектура представлява начин на дизайн на софтуер, при който услуги се предоставят на други компоненти, чрез портове за комуникация в мрежата. Основните принципи на Ориентираната към услуги архитектура са независими от конкретен доставчик, продукт или технология. Услугата е малка част преодставяща функционалност, която може да се използва от разстояние, да се използва и да се обновява независимо от останалите.
Една услуга има четири свойства според една от многото дефиниции на SOA: Услугата представлява бизнес активност със специален изход/резултат. Услугата е самостоятелна, самосъдържаща се. Услугата е черна кутия за ползвателите. Услугата може да се състои от други скрити отдолу услуги.
Различни услуги могат да се използват заедно, за да се предостави функционалност на голямо софтуерно приложение. Дефиницията на Ориентираната към услуги архитектура е модуларна програма още от 70-те години на миналия век. Ориентираната към услуги архитектура е свързана не толкова с правенето на модуларно приложение, колкото с как да съставим приложение чрез интеграция на отдалечени, отделно поддържащи се и отделно инсталирани компоненти. Това се предлага от технологии и стандарти, които правят комуникацията между отделните компоненти в мрежата лесна, особено в IP адресирана мрежа.
Преглед В Ориентираната към услуги архитектура (SOA), уеб услугите използват протоколи, които описват как те предават и трансформират (парсват) съобщения използващи описателни метаданни. Тези метаданни описват както функционалните характеристики на услугата, така и качествата на услугата. Целта е да се позволи на потребителите да комбинират големи парчета от функционалности, за да оформят нови приложения, съставени изцяло от вече съществуващи услуги, но комбинирайки ги по специален начин. Услугата предлага прост потребителски интерфейс на ползвателя и скрива излишната сложност, като за него работи като черна кутия. В същото време останалите ползватели могат да използват същите услуги независимо, без да знаят как са разработени вътрешно.
Понятия Понятието „ориентирани към услуги“(service-orientation) цели малка свързаност(loose coupling) между услугите. SOA разделя функционалностите на отдалечени елементи, или услуги, които разработчиците ги правят достъпни в мрежата за да позволят на ползвателите на услугите да ги комбинират и преизползват разработвайки приложенията. Тези услуги и техните ползватели(консуматори) комуникират един с друг като предават данни в добре структуриран и разпространен формат, или като координират активностите между две или повече услуги.
През октомври 2009 е публикувана декларация за SOA. Декларират се шест основни стойности, които са показани както следва: Бизнес стойността е по-важна от техничеката стратегия. Стратегическите цели са по-важни от специфичните за проекта ползи. Съществената оперативна съвместимост е по-важна от конкретната интеграция. Споделените услуги са по-важни от конкретните имплементации. Гъвкавостта е по-важна от оптимизациите. Постоянното усъвършенстване е по-важно от преследването на първоначално завършеност.
SOA може да бъде продължение на започналото още преди време като концепция – разпределени изчислителни системиThomas Erl (June 2005). About the Principles. Serviceorientation.org и модуларно програмиране, през SOA, и до днешните практики като хибридни приложения(mashup)s, SaaS, and облачни услуги (което някои виждат като естествено продължние на SOA).
Принципи на SOA Няма официални стандарти наложени от индустрията, свързани с точната композиция на Ориентираната към услуги архитектура, въпреки това много компании имат свои собствени принципи. Някои от тезиYvonne Balzer Improve your SOA project plans, IBM, 16 юли 2004Principles by Thomas Erl of SOA Systems Inc. eight specific service-orientation principles включват следното: Стандартизирани условия на услугите Успугите се придържат към стардартни комуникационни условия, като се дефинират от един или повече документи, описващи услугите за дадения набор от услуги. Автономност на връзката между услугите (част от loose coupling) Връзката между услугите е минимализирана да ниво, в което те знаят само за тяхното съществуне. Прозрачност на местоположението на услугите (част от loose coupling) Услугите могат да бъдат извикани от всякъде в мрежата, без значение къде се намират. Дълголетие на услугата Услугите могат да се проектират така, че да имат дълъг живот. Където е възможно услугите трябва да избягват налагането над ползвателите да се променят ако те не желаят да се добавят нови функционалности. В сила трябва да е следното правило „ако извикаш една услуга днес, трябва да можеш да извикаш същата услуга и утре“. Абстрактни услуги Услугите трябва да работят като черна кутия, по този начин тяхната вътрешна логика е скрита от ползвателите. Автономни услуги Услугите са независими и контролират функционалностите които скриват, от страна на Design-time(времето за разработка) и run-time(времето за действие). Услуги без състояние Услугите нямат състояние, те или връщат пожелания резултат, или връщат изключение(exception). Едно извикване на услугата не трябва да влияе на друго такова. Принцип на детайлност на услугата Принцип целящ да подсигуре, че услигата ще има адекватен размер и обхват. Функционалностите предоставени на ползвателя от услугата трябва да бъдат уместни. Нормализиране на услуга Услугите се декомпозират и консолидират(нормализират), за да се намали излишното. За някои услуги това не може да се направи, това са случаите в които бързодействието, достъпа и агрегацията са нужни.2004 Композитност на услуги Услугите могат да се използват за да се композират други услуги. Откриване на услуги Услугите имат специални коминикационни метаданни чрез които услугите лесно могат да се откриват. Преизползване на услуги Логиката е разделена на малки парчета, което позволява отделни малки услуги и тяхното лесно преизползване. Енкапцулация на услуги Много услуги, които не в началото не са планирани като SOA, могат да се енкапсулират(обвият) и да станат част от SOA.
Структура Всяка SOA може да играе една от следните три роли в изграждането на приложението: Доставчик на услуги(Service provider) Той създава уеб услугата и предоставя информацията свързана с услугата на регистъра с услуги(service registry). Всеки доставчик има несигурности, и се дебатира върху многото „защо“ и „как“, коя услуга да се предостави за използване и на коя да се даде по-голяма важност: сигурност или лесна достъпност, на каква цена да се предоставя услугата и още много. Доставчика на услугата също трябва да реши в коя категория попада услугата в списъка на конкретните брокери на услуги, а също и какви са условията за ползване на услугата. Брокер на услуги(Service broker), регистър на услуги(service registry) или хранилище на услуги(service repository) Техните функции са свързани с това да направят информацията(без значение от услугата) на разположение за всеки потенциален ползвател. Този, който имплементира брокера решава и какъв да е обхвата на този брокер. Публичните брокери са на разположение навсякъде, а частните(privite) брокери са лимитирани само до определен брой ползватели. UDDI е ранният, но вече не поддържан опит да се предостави откриване на уеб услуги(Web services discovery). Ползвател/консуматор на услуги Той локализира услугите в регистъра на брокерите, използвайки голям набор от търсещи операции и след това ги свързва с доставчика на услугите, за може да извика някоя от неговите уеб услуги. Която и услуга да търсят консуматорите, те първо трябва да я потърсят при брокерите, да се свържат с конкретната услуга и след това да я използват. Те могат да използват множество услуги, стига доставчика да предоставя повече от една услуга.
Връзката между консуматор(ползвател)-доставчик се определя от договор на услуги(service contract), който има бизнес част, функционална част и техничека част.
Композитността на услугите има два големи архитектурни стилове, намиращи се на високо равнище: Хореография и оркестрация. Ниско ниво ентърпрайз шаблони за интеграция(Enterprise Integration Patterns), които не са свързани с точен архитектурен стил и продължават да са приложими и приемливи при SOA дизайна.K. Julisch et al., Compliance by Design – Bridging the Chasm between Auditors and IT Architects. Computers & Security, Elsevier. Volume 30, Issue 6 – 7, Sep.-Oct. 2011.
Начини на имплементация Ориентираната към услуги архитектура може да бъде имплементирана чрез уеб услуги.Brandner, M., Craes, M., Oellermann, F., Zimmermann, O., Web Services-Oriented Architecture in Production in the Finance Industry, Informatik-Spektrum 02/2004, Springer-Verlag, 2004 Това се прави, за да се направят функционалните градивни блокове на приложението достъпни чрез стандартни интернет протоколи, които са независими от конкретна платформа или програмен език. Тези услуги могат да се представят или като нови приложения, или като обвивки на вече съществуващи стари системи, правейки ги уеб активни.
Имлементаторите често създават SOA използвайки стандартите за уеб услуги(като например SOAP) който набира голяма публична приемственост след предложението на версия 1.2 от W3C (World Wide Web Consortium) през 2003. Тези стандарти (още реферирани като списък със спецификации на уеб услуги) също предоставят голяма оперативна съвместимост и предпазват от крайно обвързване с някой доставчик на софтуер. Разбира се SOA може да се имплементира използвайки всяка базирана на услуги технология, като например Jini, CORBA или REST.
Източници
Вижте също Облачни изчисления
Външни препратки Service-oriented architecture (SOA) definition
Категория:Уеб услуги Категория:Бизнес модели