close

Architektura orientovaná na služby

Přejít na navigaci Přejít na hledání

V oblasti informačních technologií anglický termín Service - Oriented Architecture (SOA) obecně označuje softwarovou architekturu vhodnou pro podporu používání webových služeb pro zajištění interoperability mezi různými systémy tak, aby bylo možné používat jednotlivé aplikace jako součásti podniku. zpracovávat a plnit požadavky uživatelů integrovaným a transparentním způsobem.

Image
Prvky SOA, Dirk Krafzig, Karl Banke a Dirk Slama. Enterprise SOA . Prentice Hall, 2005

Stávající definice

Architektura orientovaná na služby je navržena tak, aby na vyžádání připojovala výpočetní zdroje (hlavně aplikace a data) k dosažení daného výsledku pro uživatele, kterými mohou být koncoví uživatelé nebo jiné služby. Organizace pro rozvoj standardů strukturovaných informací definuje architekturu orientovanou na služby následovně:

„Paradigmatem organizace je použití distribuovaných zdrojů, které mohou být pod kontrolou domén různého vlastnictví. Poskytuje jednotný způsob nabízení, objevování, interakce a používání schopností k dosažení požadovaných efektů v souladu s měřitelnými předpoklady a očekáváními.

Organizace pro rozvoj standardů strukturovaných informací

Navzdory skutečnosti, že existuje více definic architektury orientované na služby , pouze skupina Organizace pro rozvoj strukturovaných informačních standardů vytvořila formální definici, která je hluboce použitelná jak pro technologické, tak pro obchodní domény.

Ačkoli mnoho definic architektury orientované na služby je omezeno na technologii nebo pouze webové služby, tento aspekt je u dodavatelů technologií převládající. V roce 2003 hovořili o webových službách a v roce 2006 o Process Engines propojených s Business Process Model Notation.

Manifest

Manifest SOA zní:

„Orientace na služby je paradigma, které ohraničuje to, co děláte. Service Oriented Architecture (SOA) je typ architektury založený na aplikaci orientace na služby. Orientujeme se na služby, abychom důsledně povzbuzovali organizace k poskytování udržitelného obchodního výkonu, snadnějšímu použití a efektivitě nákladů a zároveň se přizpůsobovali měnícím se obchodním potřebám. Naše zkušenosti nás vedou k tomu, že upřednostňujeme:

  • Obchodní hodnota versus technický aspekt
  • Ke strategickým cílům s ohledem na konkrétní přínosy projektu
  • K vnitřní interoperabilitě versus vlastní integrace
  • Ke sdíleným službám versus konkrétní implementace
  • Flexibilita versus optimalizace
  • K evolučnímu zlepšování s ohledem na hledání počáteční dokonalosti

To znamená, že zatímco oceňujeme hodnotu prvků zobrazených vpravo, dáváme přednost prvkům zobrazeným vlevo."

( Manifest SOA )

Popis

V kontextu architektury orientované na služby je tedy možné relativně jednodušším způsobem modifikovat způsoby interakce mezi službami nebo kombinaci, ve které se služby v procesu používají. Navíc je jednodušší přidávat nové služby a upravovat procesy tak, aby vyhovovaly specifickým obchodním potřebám. Tím již není obchodní proces vázán na konkrétní platformu nebo aplikaci; ale lze jej považovat za součást většího procesu, a proto jej lze znovu použít nebo upravit.

Servisně orientovaná architektura je vhodná zejména pro společnosti s mírnou složitostí procesů a aplikací. Ve skutečnosti je interakce mezi různými společnostmi usnadněna. Podniky nyní mohou rozvíjet efektivní procesy jak interně, tak externě. Zároveň se zvyšuje flexibilita a přizpůsobivost procesů.

Zatímco mnoho společností nabízí produkty, které mohou tvořit základ architektury orientované na služby , je třeba zdůraznit, že architektura orientovaná na služby není produkt.

Klíč spočívá v naprosté absenci obchodní logiky na klientovi SOA, který je zcela agnostický s ohledem na implementační platformu, pokud jde o protokoly, vazby, typ dat, zásady, se kterými bude služba produkovat požadované informace. To vše ve prospěch nezávislosti služeb, které lze volat k provedení svých úkolů standardním způsobem, aniž by služba znala volající aplikaci a aniž by aplikace znala nebo potřebovala mít službu, kterou má. skutečně provede operaci.

Service-Oriented Architecture lze také chápat jako styl architektury informačních systémů , který umožňuje tvorbu vyvinutých aplikací, kombinující volně propojené služby a jejich interoperabilitu. Tyto služby interagují podle formální definice, nazývané protokol nebo smlouva, jako u jazyka popisu webových služeb nezávisle na základní platformě a vývojových technologiích (jako je Java, .NET atd.). Výše uvedená aplikace může například používat služby napsané v Javě pomocí platformy Java EE a služby v C # s .NET. Aplikace běžící na jedné platformě mohou také využívat služby běžící na jiných platformách, například s webovými službami, a tím usnadnit opětovné použití.

Architektura orientovaná na služby může podporovat integraci a konsolidaci činností v rámci komplexních obchodních systémů (systémy EAI ), ale nespecifikuje ani neposkytuje metodiku nebo rámec pro dokumentaci schopností a potenciálu služeb.

Jazyky na vysoké úrovni, jako je Business Process Execution Language a specifikace, jako jsou Web Services Choreography Description Language a WS-Coordination rozšiřují koncept služby a poskytují metodu pro definování a podporu koordinace dokončovacích služeb s hlavními, které následně , mohou být zahrnuty do řídicích toků a obchodních procesů implementovaných pomocí kompozitních aplikací nebo portálů.

Související technologie

Mezi technologie, které vám umožňují vytvářet architektury orientované na služby, patří:

  • komunikační sítě , bez kterých by nebylo možné komunikovat aplikace umístěné na různých serverech;
  • webové služby , které umožňují definovat způsoby komunikace různých aplikací;
  • Enterprise Service Bus (ESB), která má za úkol koordinovat a organizovat různé aplikace pro provádění obchodních funkcí.

Související komunikační protokoly

Servisně orientované výpočty nejsou vázány na konkrétní technologii. Toho lze dosáhnout pomocí široké škály technologií, včetně:

Je třeba zdůraznit, že aby byla architektura definována jako servisně orientovaná , musí komunikační protokol umožňovat i definici služeb, vstupních a výstupních parametrů, jak je tomu například u Web Services Description Language .

Několik protokolů uvedených výše předchází definici architektury orientované na služby a je spojeno se softwarovým inženýrstvím založeným na komponentách . Když byly představeny technologie související s eXtensible Markup Language, bylo jednodušší a výnosnější vytvářet architektury tohoto typu.

Aspekty vývoje

Platnost architektury orientované na služby (SOA) je důsledkem prvků a standardů, na kterých je založena. Zejména je třeba zvážit následující aspekty:

  • Otevřené standardy : pro provoz v multiplatformních prostředích je nutné, nebo alespoň vhodné, používat pouze otevřené standardy jako XML , WSDL a WS-Security (WSS).
  • Modularita : musí být nalezena správná rovnováha mezi službami poskytovanými každou jednotlivou komponentou, vytvořením vyváženého souboru malých opakovaně použitelných služeb pro běžné funkce a větších služeb pro specifické procesy. Tento aspekt je vypůjčen ze softwarového inženýrství založeného na komponentách [1] .
  • Servisní smlouvy : Popis webových služeb Jazyk je standardní specifikace pro vytváření smluv o webových službách, definovaná smlouva povede k flexibilnějším službám. Alternativou je Web Application Description Language , který umožňuje definovat služby využívající Representational State Transfer a technologii JSON .
  • Integrační rámce : implementují integrační vzory [2] a umožňují uspořádanější řízení orchestrace služeb.
  • Enterprise Service Bus : Páteř pro publikační služby a umožnění přístupu aplikací k nim. Zahrnuje také funkce, jako jsou adaptéry pro starší systémy , možnosti orchestrace služeb, autentizace a autorizace na straně zabezpečení, transformace dat, podpora obchodních pravidel a schopnost monitorovat smlouvy o úrovni služeb .

Kritika

Architektura SOA byla kritizována Martinem Fowlerem [3] a Jimem Webberem [4] . Kritika se týká složitosti koordinace mezi různými webovými službami, které jsou nazývány. Obvykle se pro tento úkol používá proprietární produkt Enterprise Service Bus. Tento proprietární produkt v sobě skrývá složitost koordinace různých komponent. Postupem času je změna konfigurací ESB stále obtížnější a existuje tendence ESB již nepoužívat, ale nechat si komponenty přímo volat, čímž se znovu zobrazí problémy, které se ESB rozhodl vyřešit.

Microservice

Mikroslužby mají úzké spojení s architekturou orientovanou na služby, ve skutečnosti je styl vývoje mikroslužeb velmi podobný stylu, který propagují ti, kteří podporují SOA. Rozdíl je v tom, že sběrnice Enterprise Service Bus byly často používány k integraci monolitických aplikací.

Snaha skrýt složitost integrace v rámci Enterprise Service Buses podle Martina Fowlera vedla k projektům, které trvaly několik let a stály miliony dolarů, ale nepřinesly žádnou hodnotu. Ještě horší je, že vedly k centralizovaným vzorcům vedení, které bránily změnám a znesnadňovaly pozorování těchto problémů.

Martin Fowler píše:

„Když jsme mluvili o mikroslužbách, běžnou otázkou je, zda se jedná pouze o architekturu orientovanou na služby (SOA), kterou jsme viděli před deseti lety. Tento bod má své opodstatnění, protože styl mikroslužeb je velmi podobný tomu, co někteří zastánci SOA podporovali. Problém je však v tom, že SOA znamená příliš mnoho různých věcí a že většinou, když narazíme na něco, co se nazývá „SOA“, je to výrazně odlišné od stylu, který zde popisujeme, obvykle kvůli zaměření na ESB zvyklé na integrovat monolitické aplikace.

Zejména jsme viděli tolik zpackaných implementací orientace na služby – od tendence skrývat složitost v ESB přes neúspěšné mnohaleté iniciativy, které stojí miliony a nepřinášejí žádnou hodnotu, až po centralizované modely řízení, které aktivně brání změnám, že někdy těžké vidět přes tyto problémy.

Mnoho technik používaných v komunitě mikroslužeb jistě vyrostlo ze zkušeností vývojářů integrujících služby ve velkých organizacích. Vzor Tolerant Reader je toho příkladem. Snahy o používání webu přispěly, používání jednoduchých protokolů je dalším přístupem odvozeným z těchto zkušeností – reakcí daleko od centrálních standardů, které dosáhly složitosti, která je, upřímně řečeno, dechberoucí. (Kdykoli budete potřebovat ontologii ke správě svých ontologií, víte, že jste v hlubokých potížích.)

Tento běžný projev SOA vedl některé zastánce mikroslužeb k úplnému odmítnutí označení SOA, ačkoli jiní považují mikroslužby za jednu z forem SOA, možná správně provedenou orientaci na služby. Ať tak či onak, skutečnost, že SOA znamená takové různé věci, znamená, že je cenné mít termín, který přesněji definuje tento architektonický styl.“

( Martin Fowler, Microservices )

Poznámky

  1. ^ Architektura orientovaná na služby (SOA) vs. Architektura založená na komponentech
  2. ^ integrační vzor
  3. ^ Mikroslužby
  4. ^ Jim Webber o "Guerilla SOA"

Bibliografie

Související položky

Další projekty

Externí odkazy

Definice architektury orientované na služby

Převzato z " https://it.wikipedia.org/w/index.php?title=Service-oriented_architecture&oldid=125740983 "