Уикипедия

SOA

компонентна компютърна архитектура базирана на web services

Ориентираната към услуги архитектура (на английски: Service-oriented architecture – SOA) е начин за асемблиране на софтуерни приложения, инженеринг и бизнес процеси чрез свързване на софтуерни услуги. Програмистите разработват тези услуги използвайки традиционни езици като Java, C, C++, C#, Visual Basic, COBOL или PHP. Ориентираната към услуги архитектура представлява начин на дизайн на софтуер, при който услуги се предоставят на други компоненти, чрез портове за комуникация в мрежата. Основните принципи на Ориентираната към услуги архитектура са независими от конкретен доставчик, продукт или технология.[1] Услугата е малка част преодставяща функционалност, която може да се използва от разстояние, да се използва и да се обновява независимо от останалите.

Една услуга има четири свойства според една от многото дефиниции на SOA:[2]

  1. Услугата представлява бизнес активност със специален изход/резултат.
  2. Услугата е самостоятелна, самосъдържаща се.
  3. Услугата е черна кутия за ползвателите.
  4. Услугата може да се състои от други скрити отдолу услуги.[3]

Различни услуги могат да се използват заедно, за да се предостави функционалност на голямо софтуерно приложение.[4] Дефиницията на Ориентираната към услуги архитектура е модуларна програма още от 70-те години на миналия век. Ориентираната към услуги архитектура е свързана не толкова с правенето на модуларно приложение, колкото с как да съставим приложение чрез интеграция на отдалечени, отделно поддържащи се и отделно инсталирани компоненти. Това се предлага от технологии и стандарти, които правят комуникацията между отделните компоненти в мрежата лесна, особено в IP адресирана мрежа.

Преглед редактиране

В Ориентираната към услуги архитектура (SOA), уеб услугите използват протоколи, които описват как те предават и трансформират (парсват) съобщения използващи описателни метаданни. Тези метаданни описват както функционалните характеристики на услугата, така и качествата на услугата. Целта е да се позволи на потребителите да комбинират големи парчета от функционалности, за да оформят нови приложения, съставени изцяло от вече съществуващи услуги, но комбинирайки ги по специален начин. Услугата предлага прост потребителски интерфейс на ползвателя и скрива излишната сложност, като за него работи като черна кутия. В същото време останалите ползватели могат да използват същите услуги независимо, без да знаят как са разработени вътрешно.[5]

Понятия редактиране

Понятието „ориентирани към услуги“(service-orientation) цели малка свързаност(loose coupling) между услугите. SOA разделя функционалностите на отдалечени елементи, или услуги,[6] които разработчиците ги правят достъпни в мрежата за да позволят на ползвателите на услугите да ги комбинират и преизползват разработвайки приложенията. Тези услуги и техните ползватели(консуматори) комуникират един с друг като предават данни в добре структуриран и разпространен формат, или като координират активностите между две или повече услуги.[7]

През октомври 2009 е публикувана декларация за SOA. Декларират се шест основни стойности, които са показани както следва:[8]

  1. Бизнес стойността е по-важна от техничеката стратегия.
  2. Стратегическите цели са по-важни от специфичните за проекта ползи.
  3. Съществената оперативна съвместимост е по-важна от конкретната интеграция.
  4. Споделените услуги са по-важни от конкретните имплементации.
  5. Гъвкавостта е по-важна от оптимизациите.
  6. Постоянното усъвършенстване е по-важно от преследването на първоначално завършеност.

SOA може да бъде продължение на започналото още преди време като концепция – разпределени изчислителни системи[6][9] и модуларно програмиране, през SOA, и до днешните практики като хибридни приложения(mashup)s, SaaS, and облачни услуги (което някои виждат като естествено продължние на SOA).[10]

Принципи на SOA редактиране

Няма официални стандарти наложени от индустрията, свързани с точната композиция на Ориентираната към услуги архитектура, въпреки това много компании имат свои собствени принципи. Някои от тези[11][12][13][14] включват следното:

Стандартизирани условия на услугите
Успугите се придържат към стардартни комуникационни условия, като се дефинират от един или повече документи, описващи услугите за дадения набор от услуги.
Автономност на връзката между услугите (част от loose coupling)
Връзката между услугите е минимализирана да ниво, в което те знаят само за тяхното съществуне.
Прозрачност на местоположението на услугите (част от loose coupling)
Услугите могат да бъдат извикани от всякъде в мрежата, без значение къде се намират.
Дълголетие на услугата
Услугите могат да се проектират така, че да имат дълъг живот. Където е възможно услугите трябва да избягват налагането над ползвателите да се променят ако те не желаят да се добавят нови функционалности. В сила трябва да е следното правило „ако извикаш една услуга днес, трябва да можеш да извикаш същата услуга и утре“.
Абстрактни услуги
Услугите трябва да работят като черна кутия, по този начин тяхната вътрешна логика е скрита от ползвателите.
Автономни услуги
Услугите са независими и контролират функционалностите които скриват, от страна на Design-time(времето за разработка) и run-time(времето за действие).
Услуги без състояние
Услугите нямат състояние, те или връщат пожелания резултат, или връщат изключение(exception). Едно извикване на услугата не трябва да влияе на друго такова.
Принцип на детайлност на услугата
Принцип целящ да подсигуре, че услигата ще има адекватен размер и обхват. Функционалностите предоставени на ползвателя от услугата трябва да бъдат уместни.
Нормализиране на услуга
Услугите се декомпозират и консолидират(нормализират), за да се намали излишното. За някои услуги това не може да се направи, това са случаите в които бързодействието, достъпа и агрегацията са нужни.[15]
Композитност на услуги
Услугите могат да се използват за да се композират други услуги.
Откриване на услуги
Услугите имат специални коминикационни метаданни чрез които услугите лесно могат да се откриват.
Преизползване на услуги
Логиката е разделена на малки парчета, което позволява отделни малки услуги и тяхното лесно преизползване.
Енкапцулация на услуги
Много услуги, които не в началото не са планирани като SOA, могат да се енкапсулират(обвият) и да станат част от SOA.

Структура редактиране

Всяка SOA може да играе една от следните три роли в изграждането на приложението:

Доставчик на услуги(Service provider)
Той създава уеб услугата и предоставя информацията свързана с услугата на регистъра с услуги(service registry). Всеки доставчик има несигурности, и се дебатира върху многото „защо“ и „как“, коя услуга да се предостави за използване и на коя да се даде по-голяма важност: сигурност или лесна достъпност, на каква цена да се предоставя услугата и още много. Доставчика на услугата също трябва да реши в коя категория попада услугата в списъка на конкретните брокери на услуги, а също и какви са условията за ползване на услугата.
Брокер на услуги(Service broker), регистър на услуги(service registry) или хранилище на услуги(service repository)
Техните функции са свързани с това да направят информацията(без значение от услугата) на разположение за всеки потенциален ползвател. Този, който имплементира брокера решава и какъв да е обхвата на този брокер. Публичните брокери са на разположение навсякъде, а частните(privite) брокери са лимитирани само до определен брой ползватели. UDDI е ранният, но вече не поддържан опит да се предостави откриване на уеб услуги(Web services discovery).
Ползвател/консуматор на услуги
Той локализира услугите в регистъра на брокерите, използвайки голям набор от търсещи операции и след това ги свързва с доставчика на услугите, за може да извика някоя от неговите уеб услуги. Която и услуга да търсят консуматорите, те първо трябва да я потърсят при брокерите, да се свържат с конкретната услуга и след това да я използват. Те могат да използват множество услуги, стига доставчика да предоставя повече от една услуга.

Връзката между консуматор(ползвател)-доставчик се определя от договор на услуги(service contract), който има бизнес част, функционална част и техничека част.

Композитността на услугите има два големи архитектурни стилове, намиращи се на високо равнище: Хореография и оркестрация. Ниско ниво ентърпрайз шаблони за интеграция(Enterprise Integration Patterns), които не са свързани с точен архитектурен стил и продължават да са приложими и приемливи при SOA дизайна.[16][17][18]

Начини на имплементация редактиране

Ориентираната към услуги архитектура може да бъде имплементирана чрез уеб услуги.[19] Това се прави, за да се направят функционалните градивни блокове на приложението достъпни чрез стандартни интернет протоколи, които са независими от конкретна платформа или програмен език. Тези услуги могат да се представят или като нови приложения, или като обвивки на вече съществуващи стари системи, правейки ги уеб активни.[20]

Имлементаторите често създават SOA използвайки стандартите за уеб услуги(като например SOAP) който набира голяма публична приемственост след предложението на версия 1.2 от W3C[21] (World Wide Web Consortium) през 2003. Тези стандарти (още реферирани като списък със спецификации на уеб услуги) също предоставят голяма оперативна съвместимост и предпазват от крайно обвързване с някой доставчик на софтуер. Разбира се SOA може да се имплементира използвайки всяка базирана на услуги технология, като например Jini, CORBA или REST.

Източници редактиране

  1. ↑ Chapter 1: Service Oriented Architecture (SOA) // msdn.microsoft.com. Посетен на 21 септември 2016.
  2. ↑ www.opengroup.org, архив на оригинала от 3 ноември 2017, https://web.archive.org/web/20171103180220/http://opengroup.org/standards/soa, посетен на 3 февруари 2017 
  3. ↑ What Is SOA? // www.opengroup.org. Посетен на 21 септември 2016.
  4. ↑ Velte, Anthony T. Cloud Computing: A Practical Approach. McGraw Hill, 2010. ISBN 978-0-07-162694-1.
  5. ↑ Migrating to a service-oriented architecture, Part 1 // 9 декември 2008. Архивиран от оригинала на 2008-12-09. Посетен на 21 септември 2016.
  6. ↑ а б Michael Bell. Introduction to Service-Oriented Modeling // Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons, 2008. ISBN 978-0-470-14111-3. с. 3.
  7. ↑ Michael Bell. SOA Modeling Patterns for Service-Oriented Discovery and Analysis. Wiley & Sons, 2010. ISBN 978-0-470-48197-4. с. 390.
  8. ↑ SOA Manifesto // www.soa-manifesto.org. Архивиран от оригинала на 2017-07-25. Посетен на 21 септември 2016.
  9. ↑ Thomas Erl (June 2005). About the Principles. Serviceorientation.org
  10. ↑ Application Platform Strategies Blog: SOA is Dead; Long Live Services // Apsblog.burtongroup.com, 5 януари 2009. Архивиран от оригинала на 2009-01-15. Посетен на 13 август 2012.
  11. ↑ Yvonne Balzer Improve your SOA project plans, IBM, 16 юли 2004
  12. ↑ Microsoft Windows Communication Foundation team. Principles of Service Oriented Design // msdn.microsoft.com. 2012. Посетен на 3 септември 2012.
  13. ↑ Principles by Thomas Erl of SOA Systems Inc. eight specific service-orientation principles
  14. ↑ M. Hadi Valipour. A brief survey of software architecture concepts and service oriented architecture // 2009 2nd IEEE International Conference on Computer Science and Information Technology. 2009. ISBN 978-1-4244-4519-6. DOI:10.1109/ICCSIT.2009.5235004. с. 34 – 38.
  15. ↑ Tony Shan. Building a service-oriented e Banking platform // IEEE International Conference on Services Computing, 2004. (SCC 2004). Proceedings. 2004. 2004. ISBN 0-7695-2225-4. DOI:10.1109/SCC.2004.1358011. с. 237 – 244.2004
  16. ↑ Olaf Zimmermann, Cesare Pautasso, Gregor Hohpe, Bobby Woolf. A Decade of Enterprise Integration Patterns // IEEE Software 33 (1). 2016. DOI:10.1109/MS.2016.11. с. 13 – 19.
  17. ↑ Rotem-Gal-Oz, Arnon. SOA Patterns. Manning Publications, 2012. ISBN 978-1933988269.
  18. ↑ 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.
  19. ↑ 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
  20. ↑ www.ibm.com // Посетен на 10 септември 2016.
  21. ↑ SOAP Version 1.2 の公開について (W3C 勧告) // W3.org. Посетен на 13 август 2012. (на японски)

Вижте също редактиране

Външни препратки редактиране

    Тази страница частично или изцяло представлява превод на страницата Service-oriented architecture в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс – Признание – Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година – от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница, за да видите списъка на съавторите. ​

ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни.​

Взето от „https://bg.wikipedia.org/w/index.php?title=SOA&oldid=12022741“.