Architektura orientovaná na služby - Service-oriented architecture

V softwarovém inženýrství je architektura orientovaná na služby ( SOA ) architektonický styl, který podporuje orientaci na služby. V důsledku toho je také aplikován v oblasti návrhu softwaru, kde jsou služby poskytovány ostatním komponentám aplikačními komponentami prostřednictvím komunikačního protokolu přes síť. Služba je samostatná jednotka funkcí, ke které lze přistupovat na dálku, jednat podle ní a aktualizovat ji nezávisle, například načítání výpisu z kreditní karty online. SOA má být také nezávislý na prodejcích, produktech a technologiích.

Orientace na služby je způsob myšlení z hlediska služeb a vývoje založeného na službách a výsledků služeb.

Služba má čtyři vlastnosti podle jedné z mnoha definic SOA:

  1. Logicky to představuje opakovatelnou obchodní aktivitu se zadaným výsledkem.
  2. Je to soběstačné.
  3. Pro jeho spotřebitele je to černá skříňka , což znamená, že si spotřebitel nemusí být vědom vnitřního fungování služby.
  4. Může být složen z dalších služeb.

Různé služby mohou být použity ve spojení jako síť služeb k zajištění funkčnosti velké softwarové aplikace , což je princip, který SOA sdílí s modulárním programováním . Architektura orientovaná na služby integruje distribuované, samostatně udržované a nasazené softwarové komponenty. Umožňují to technologie a standardy, které usnadňují komunikaci a spolupráci komponent v síti, zejména v síti IP.

SOA souvisí s myšlenkou rozhraní pro programování aplikací (API), rozhraní nebo komunikačního protokolu mezi různými částmi počítačového programu určeného ke zjednodušení implementace a údržby softwaru. API lze považovat za službu a SOA za architekturu, která umožňuje provoz služby.

Přehled

V SOA používají služby protokoly, které popisují, jak předávají a analyzují zprávy pomocí metadat popisu . Tato metadata popisují funkční charakteristiky služby i vlastnosti kvality služby. Architektura orientovaná na služby si klade za cíl umožnit uživatelům kombinovat velké části funkcí a vytvářet aplikace, které jsou postaveny čistě ze stávajících služeb, a kombinovat je ad hoc. Služba představuje pro žadatele jednoduché rozhraní, které abstrahuje základní složitost a funguje jako černá skříňka. K těmto nezávislým službám mají přístup i další uživatelé bez znalosti jejich interní implementace.

Definování pojmů

Související propagace orientace na službu v oblasti buzzword je volné propojení mezi službami. SOA odděluje funkce do odlišných jednotek nebo služeb, které vývojáři zpřístupňují prostřednictvím sítě, aby je uživatelé mohli kombinovat a znovu použít při výrobě aplikací. Tyto služby a jejich odpovídající spotřebitelé spolu komunikují předáváním dat v dobře definovaném sdíleném formátu nebo koordinací činnosti mezi dvěma nebo více službami.

Manifest byl publikován pro architekturu orientovanou na služby v říjnu 2009. Přišlo se šesti základními hodnotami, které jsou uvedeny následovně:

  1. Obchodní hodnotě je přikládán větší význam než technické strategii.
  2. Strategickým cílům je přikládán větší význam než přínosům pro konkrétní projekty.
  3. Vnitřní interoperabilita má větší význam než vlastní integrace.
  4. Sdílené služby mají větší význam než implementace pro konkrétní účely.
  5. Flexibilita má větší význam než optimalizace.
  6. Evoluční zdokonalení je přikládáno větší důležitosti než snaha o počáteční dokonalost.

SOA lze považovat za součást kontinua, které sahá od staršího konceptu distribuovaných počítačů a modulárního programování , přes SOA a dále k praktikám mashupů , SaaS a cloud computingu (které někteří považují za potomky SOA).

Zásady

Neexistují žádné průmyslové standardy týkající se přesného složení architektury orientované na služby, ačkoli mnoho průmyslových zdrojů zveřejnilo své vlastní principy. Některé z nich zahrnují následující:

Standardizovaná servisní smlouva
Služby dodržují standardní komunikační smlouvu definovanou souhrnně jedním nebo více dokumenty s popisem služby v rámci dané sady služeb.
Autonomie referenčních služeb (aspekt volné vazby)
Vztah mezi službami je minimalizován na úroveň, že si jsou vědomi pouze své existence.
Průhlednost umístění služby (aspekt volné vazby)
Služby lze volat odkudkoli v rámci sítě, na které se nachází, bez ohledu na to, kde se nachází.
Životnost služby
Služby by měly být navrženy tak, aby byly dlouhodobé. Pokud je to možné, služby by neměly nutit spotřebitele ke změně, pokud nevyžadují nové funkce, pokud zavoláte službu dnes, měli byste mít možnost volat stejnou službu zítra.
Abstrakce služby
Služby fungují jako černé skříňky, to znamená, že jejich vnitřní logika je skrytá před spotřebiteli.
Autonomie služby
Služby jsou nezávislé a kontrolují funkce, které zapouzdřují, z hlediska návrhu a běhu.
Bezstavová služba
Služby jsou bez státní příslušnosti, tj. Buď vrácení požadované hodnoty, nebo poskytnutí výjimky, a tedy minimalizace využití prostředků.
Zrnitost služby
Zásada zajištění adekvátní velikosti a rozsahu služeb. Funkčnost poskytovaná službou uživateli musí být relevantní.
Normalizace služby
Služby se rozkládají nebo konsolidují (normalizují), aby se minimalizovala nadbytečnost. U některých to nemusí být provedeno. To jsou případy, kdy je vyžadována optimalizace výkonu, přístup a agregace.
Složitelnost služby
Služby lze použít k sestavení dalších služeb.
Zjištění služby
Služby jsou doplněny o komunikační metadata, pomocí kterých je lze efektivně objevovat a interpretovat.
Opakovaná použitelnost služby
Logika je rozdělena na různé služby, aby podpořila opětovné použití kódu.
Zapouzdření služby
Mnoho služeb, které nebyly původně plánovány v rámci SOA, se mohou zapouzdřit nebo se stát součástí SOA.

Vzory

Každý stavební blok SOA může hrát kteroukoli ze tří rolí:

Poskytovatel služeb
Vytvoří webovou službu a poskytne její informace registru služeb. Každý poskytovatel debatuje o tom, jak a proč, jaké služby vystavit, které dát větší důležitost: bezpečnost nebo snadná dostupnost, za jakou cenu nabídnout službu a mnoho dalších . Poskytovatel také musí rozhodnout, v jaké kategorii by měla být služba uvedena pro danou službu makléře a jaký druh dohod o obchodních partnerech je vyžadován k používání služby.
Servisní makléř, registr služeb nebo úložiště služeb
Jeho hlavní funkcí je zpřístupnit informace týkající se webové služby jakémukoli potenciálnímu žadateli. O tom, kdo brokera implementuje, rozhoduje rozsah brokera. Veřejní makléři jsou k dispozici kdekoli a všude, ale soukromí makléři jsou k dispozici pouze omezenému množství veřejnosti. UDDI byl raný, již aktivně nepodporovaný pokus o poskytování zjišťování webových služeb .
Žadatel služby/spotřebitel
Lokalizuje položky v registru makléřů pomocí různých operací hledání a poté se váže na poskytovatele služeb, aby vyvolal jednu z jeho webových služeb. Bez ohledu na službu, kterou služba spotřebitelé potřebují, musí ji převést na makléře, spojit ji s příslušnou službou a poté použít. Pokud služba poskytuje více služeb, mohou přistupovat k více službám.

Vztah mezi spotřebitelem a poskytovatelem služeb se řídí standardizovanou smlouvou o poskytování služeb , která má obchodní část, funkční část a technickou část.

Vzory kompozice služeb mají dva široké architektonické styly na vysoké úrovni: choreografii a orchestraci . Integrační vzorce nižší úrovně podnikání, které nejsou vázány na konkrétní architektonický styl, jsou i nadále relevantní a vhodné pro návrh SOA.

Implementační přístupy

Architekturu orientovanou na služby lze implementovat pomocí webových služeb nebo mikroslužeb . To se provádí za účelem zpřístupnění funkčních bloků prostřednictvím standardních internetových protokolů, které jsou nezávislé na platformách a programovacích jazycích. Tyto služby mohou představovat buď nové aplikace, nebo jen obaly kolem stávajících starších systémů, aby byly podporovány sítí.

Implementátoři běžně vytvářejí SOA pomocí standardů webových služeb. Jedním z příkladů je SOAP , který získal široké přijetí v oboru po doporučení verze 1.2 od W3C (World Wide Web Consortium) v roce 2003. Tyto standardy (označované také jako specifikace webových služeb ) také zajišťují větší interoperabilitu a určitou ochranu před zablokováním na software proprietárního dodavatele. Lze však také implementovat SOA pomocí jakékoli jiné technologie založené na službách, jako je Jini , CORBA , Internet Communications Engine , REST nebo gRPC .

Architektury mohou fungovat nezávisle na konkrétních technologiích, a proto je lze implementovat pomocí široké škály technologií, včetně:

Implementace mohou používat jeden nebo více z těchto protokolů a například mohou používat mechanismus souborového systému ke komunikaci dat podle definované specifikace rozhraní mezi procesy, které jsou v souladu s konceptem SOA. Klíčem jsou nezávislé služby s definovanými rozhraními, která lze volat k plnění jejich úkolů standardním způsobem, aniž by služba měla předem povědomí o volající aplikaci a aniž by aplikace měla nebo potřebovala znalosti o tom, jak služba ve skutečnosti plní své úkoly. SOA umožňuje vývoj aplikací, které jsou vytvořeny kombinací volně spojených a interoperabilních služeb.

Tyto služby spolupracují na základě formální definice (nebo smlouvy, např. WSDL), která je nezávislá na základní platformě a programovacím jazyce. Definice rozhraní skrývá implementaci služby specifické pro jazyk. Systémy založené na SOA proto mohou fungovat nezávisle na vývojových technologiích a platformách (jako je Java, .NET atd.). Služby napsané v C# běžící na platformách .NET a služby napsané například v Javě běžící na platformách Java EE mohou být obě spotřebovány běžnou kompozitní aplikací (nebo klientem). Aplikace běžící na obou platformách mohou také využívat služby běžící na druhé jako webové služby, které usnadňují opětovné použití. Spravovaná prostředí mohou také zabalit starší systémy COBOL a prezentovat je jako softwarové služby. .

Programovací jazyky na vysoké úrovni, jako je BPEL, a specifikace jako WS-CDL a WS-Coordination rozšiřují koncept služby tím, že poskytují způsob definování a podpory orchestrace jemnozrnných služeb do hrubších zrnitých obchodních služeb, což mohou architekti zase začlenit do pracovních toků a obchodních procesů implementovaných ve složených aplikacích nebo portálech .

Modelování orientované na služby je rámec SOA, který identifikuje různé disciplíny, které vedou odborníky SOA k konceptualizaci, analýze, návrhu a architektuře jejich aktiv orientovaných na služby. Rámec služby orientované modelování (SOMF) nabízí modelovací jazyk a pracovní struktura nebo „mapa“, zobrazující různé komponenty, které přispívají k úspěšné modelovací přístup orientované na služby. Ilustruje hlavní prvky, které identifikují aspekty „co dělat“ ve schématu rozvoje služeb. Tento model umožňuje odborníkům sestavit plán projektu a identifikovat milníky iniciativy orientované na služby. SOMF také poskytuje společný zápis modelování, který řeší sladění mezi obchodními a IT organizacemi.

Prvky SOA, Dirk Krafzig, Karl Banke a Dirk Slama
Meta-model SOA, The Linthicum Group, 2007

Organizační výhody

Někteří firemní architekti se domnívají, že SOA může pomoci podnikům reagovat rychleji a nákladově efektivněji na měnící se tržní podmínky. Tento styl architektury podporuje opětovné použití na úrovni makro (služba), nikoli na úrovni mikro (třídy). Může také zjednodušit propojení se stávajícími IT (staršími) aktivy a jejich používání.

U SOA jde o to, že organizace může na problém pohlížet holisticky. Firma má větší celkovou kontrolu. Teoreticky by neexistovala masa vývojářů využívajících jakékoli sady nástrojů, které by je mohly potěšit. Ale spíše by kódovali standard, který je nastaven v rámci podnikání. Mohou také vyvíjet celopodnikové SOA, které zapouzdřují infrastrukturu zaměřenou na podnikání. SOA byl také představen jako dálniční systém zajišťující účinnost pro řidiče automobilů. Jde o to, že kdyby každý měl auto, ale nikde nebyla žádná dálnice, věci by byly omezené a neorganizované při jakémkoli pokusu dostat se kamkoli rychle nebo efektivně. Viceprezident IBM pro webové služby Michael Liebow říká, že SOA „staví dálnice“.

V některých ohledech lze SOA považovat spíše za architektonický vývoj než za revoluci. Zachycuje mnoho z nejlepších postupů předchozích softwarových architektur. Například v komunikačních systémech došlo k malému vývoji řešení, která používají skutečně statické vazby k hovoru s jiným zařízením v síti. Přijetím přístupu SOA se takové systémy mohou postavit, aby zdůraznily důležitost dobře definovaných, vysoce interoperabilních rozhraní. Mezi další předchůdce SOA patří softwarové inženýrství založené na komponentách a objektově orientovaná analýza a návrh (OOAD) vzdálených objektů, například v CORBA .

Služba obsahuje samostatnou jednotku funkcí, která je k dispozici pouze prostřednictvím formálně definovaného rozhraní. Službami mohou být jakési „nanopodniky“, které se snadno vyrábějí a zlepšují. Také službami mohou být „megakorporace“ konstruované jako koordinovaná práce podřízených služeb.

Důvody pro zavádění služeb jako samostatných projektů od větších projektů zahrnují:

  1. Separace propaguje v podniku koncept, že služby lze poskytovat rychle a nezávisle na větších a pomalejších projektech běžných v organizaci. Firma začíná rozumět systémům a zjednodušeným uživatelským rozhraním využívajícím služby. To podporuje agilitu . To znamená, že podporuje obchodní inovace a zrychluje uvedení na trh.
  2. Separace podporuje oddělení služeb od náročných projektů. To podporuje dobrý design, pokud je služba navržena, aniž by věděla, kdo jsou její spotřebitelé.
  3. Dokumentace a testovací artefakty služby nejsou vloženy do detailu většího projektu. To je důležité, když je potřeba službu znovu použít později.

SOA slibuje nepřímé zjednodušení testování. Služby jsou autonomní, bez státní příslušnosti, s plně zdokumentovanými rozhraními a oddělené od průřezových starostí implementace. Pokud organizace vlastní příslušně definovaná testovací data, vytvoří se odpovídající stub, který reaguje na testovací data při vytváření služby. Pro službu je také zachycena úplná sada regresních testů, skriptů, dat a odpovědí. Službu lze testovat jako „černou skříňku“ pomocí stávajících stubů odpovídajících službám, které volá. Testovací prostředí lze vytvořit tam, kde primitivními službami a službami mimo rozsah jsou útržky, zatímco zbývající část sítě tvoří testovací nasazení plných služeb. Jelikož je každé rozhraní plně dokumentováno vlastní úplnou sadou dokumentace regresních testů, je snadné identifikovat problémy v testovacích službách. Testování se vyvíjí tak, aby pouze ověřovalo, že testovací služba funguje podle své dokumentace, a nachází mezery v dokumentaci a testovacích případech všech služeb v prostředí. Jedinou složitostí je správa datového stavu idempotentních služeb.

Příklady mohou být užitečné při dokumentaci služby na úroveň, kde se stane užitečnou. Dobrým příkladem je dokumentace některých API v rámci komunitního procesu Java. Protože jsou tyto taxativní, zaměstnanci obvykle používají pouze důležité podmnožiny. Soubor 'ossjsa.pdf' v JSR-89 je příkladem takového souboru.

Kritika

SOA byla spojena s webovými službami ; webové služby jsou však pouze jednou z možností implementace vzorů, které obsahují styl SOA. Při absenci nativních nebo binárních forem vzdáleného volání procedur (RPC) by aplikace mohly běžet pomaleji a vyžadovat větší výpočetní výkon, což by zvýšilo náklady. Většina implementací tyto režijní náklady nese, ale SOA lze implementovat pomocí technologií (například Java Business Integration (JBI), Windows Communication Foundation (WCF) a Data distribution service (DDS)), které nezávisí na vzdálených voláních procedur nebo překladu pomocí XML nebo JSON. Současně vznikající open-source technologie analýzy XML (například VTD-XML ) a různé binární formáty kompatibilní s XML slibují výrazné zlepšení výkonu SOA.

Státní služby vyžadují, aby spotřebitel i poskytovatel sdíleli stejný kontext specifický pro spotřebitele, který je buď zahrnut ve zprávách vyměňovaných mezi poskytovatelem a spotřebitelem, nebo na ně odkazují. Toto omezení má tu nevýhodu, že by mohlo snížit celkovou škálovatelnost poskytovatele služeb, pokud poskytovatel služeb potřebuje zachovat sdílený kontext pro každého spotřebitele. Rovněž zvyšuje propojení mezi poskytovatelem služeb a spotřebitelem a ztěžuje změnu poskytovatele služeb. Někteří kritici se nakonec domnívají, že služby SOA jsou stále příliš omezeny aplikacemi, které představují.

Primární výzvou, před kterou stojí architektura orientovaná na služby, je správa metadat. Prostředí založená na SOA zahrnuje mnoho služeb, které mezi sebou komunikují při plnění úkolů. Vzhledem k tomu, že návrh může zahrnovat více služeb pracujících společně, může aplikace generovat miliony zpráv. Další služby mohou patřit různým organizacím nebo dokonce konkurenčním firmám, což vytváří obrovský problém důvěry. Řízení SOA tak vstupuje do schématu věcí.

Dalším zásadním problémem, kterému SOA čelí, je nedostatek jednotného testovacího rámce. Neexistují žádné nástroje, které by poskytovaly požadované funkce pro testování těchto služeb v architektuře orientované na služby. Hlavní příčiny obtíží jsou:

  • Heterogenita a složitost řešení.
  • Obrovská sada testovacích kombinací díky integraci autonomních služeb.
  • Zahrnutí služeb od různých a konkurenčních dodavatelů.
  • Platforma se neustále mění kvůli dostupnosti nových funkcí a služeb.

Rozšíření a varianty

Architektury řízené událostmi

Rozhraní pro programování aplikací

Rozhraní API (Application Programming Interface) jsou rámce, prostřednictvím kterých mohou vývojáři komunikovat s webovou aplikací.

Web 2.0

Tim O'Reilly vytvořil termín „ Web 2.0 “ k popisu vnímané, rychle rostoucí sady webových aplikací. Téma, které má rozsáhlé pokrytí, zahrnuje vztah mezi Web 2.0 a architekturami orientovanými na služby.

SOA je filozofií zapouzdření aplikační logiky do služeb s jednotně definovaným rozhraním a jejich zpřístupňování veřejnosti prostřednictvím mechanismů zjišťování. Pojem skrývání a opětovné použití složitosti, ale také koncept volně propojených služeb inspiroval vědce k vypracování podobností mezi oběma filozofiemi, SOA a Web 2.0, a jejich příslušnými aplikacemi. Někteří tvrdí, že Web 2.0 a SOA mají výrazně odlišné prvky, a proto je nelze považovat za „paralelní filozofie“, zatímco jiní považují tyto dva pojmy za doplňkové a považují Web 2.0 za globální SOA.

Filozofie Web 2.0 a SOA slouží různým potřebám uživatelů a odhalují tak rozdíly v designu a také v technologiích používaných v reálných aplikacích. Od roku 2008 však případy použití prokázaly potenciál kombinovat technologie a principy Web 2.0 a SOA.

Microservices

Microservices jsou moderní interpretací architektur orientovaných na služby používaných k vytváření distribuovaných softwarových systémů . Služby v architektuře mikroslužeb jsou procesy, které spolu komunikují po síti za účelem splnění cíle. Tyto služby využívají technologické agnostické protokoly , které pomáhají zapouzdřit výběr jazyka a rámců, což činí jejich volbu interním problémem služby. Microservices jsou novým přístupem k implementaci a implementaci SOA, které se staly populární od roku 2014 (a po zavedení DevOps ) a které také kladou důraz na nepřetržité nasazení a další agilní postupy.

Neexistuje jediná běžně dohodnutá definice mikroslužeb. V literatuře lze nalézt následující charakteristiky a principy:

  • jemnozrnná rozhraní (k nezávisle nasaditelným službám),
  • obchodně orientovaný vývoj (např. design založený na doméně ),
  • IDEAL architektury cloudových aplikací,
  • polyglotové programování a vytrvalost,
  • lehké nasazení kontejneru,
  • decentralizované nepřetržité doručování a
  • DevOps s holistickým monitorováním služeb.

Architektury orientované na služby pro interaktivní aplikace

Interaktivní aplikace vyžadující dobu odezvy v reálném čase, například interaktivní 3D aplikace s nízkou latencí, používají specifické architektury orientované na služby, které řeší specifické potřeby takového druhu aplikací. Patří mezi ně například distribuované výpočty a komunikace optimalizované pro nízkou latenci, stejně jako správa zdrojů a instancí.

Viz také

Reference

Poslechněte si tento článek ( 54 minut )
Mluvená ikona Wikipedie
Tento zvukový soubor byl vytvořen z revize tohoto článku ze dne 27. října 2011 a neodráží následné úpravy. ( 27. 10. 2011 )