Service Oriented Architecture

Z Wikipedie, otevřené encyklopedie
Skočit na: Navigace, Hledání

Service Oriented Architecture je sada principů a metodologií, která doporučuje skládat složité aplikace a jiné systémy ze skupiny na sobě nezávislých komponent poskytujících služby.

Definice[editovat | editovat zdroj]

Zkratka SOA znamená v překladu z angličtiny architekturu orientovanou na služby. Službou zde myslíme něco, co poskytne přidanou hodnotu, v rámci firmy tedy jde o jasně definovanou podnikovou činnost jako například objednání zboží od dodavatele. V rámci aplikace to může být dílčí úkol, který je nutno splnit při obsluze uživatele. Jako příklad může posloužit aplikační mini modul, jenž zaokrouhluje čísla zobrazující se uživateli jako výsledek výpočtu. Při správném návrhu aplikace orientované na služby lze poté tuto komponentu odpojit a zapojit jinou, která bude zaokrouhlovat odlišně, aniž bychom nějak zasahovali do zbytku aplikace. Jednotlivé komponenty lze zpravidla různě kombinovat, doplňovat, případně nahrazovat jednu za druhou. Tímto přístupem se prvky v systému stávají samostatnými, systém je tedy stabilnější a také je zde výhodné rozložení zátěže na více komponent. Při výpadku jedné komponenty může být nahrazena jinou, funkční. Systém se pak lépe spravuje (při poruše komponenty lze jednoznačně určit, kde se vyskytla chyba), ale také vylepšuje, jelikož je potřeba zasahovat jen do určité komponenty a ne do celého systému. Při dodržení principů SOA ve fázi návrhu lze výsledný systém přirovnat ke známé stavebnici Lego, jejíž součásti představují jednotlivé komponenty.

Motivace[editovat | editovat zdroj]

V dnešní době se většina informačních technologií stěhuje do prostředí webu, čímž se zajišťuje maximální dostupnost služeb a maximalizuje se tak počet uživatelů a tím i potenciál aplikace. Informační technologie, jakkoliv se od sebe jedna od druhé odlišují, jsou nyní postupně svazovány k sobě. Základním pojítkem, které toto umožňuje je právě SOA, tedy principy, které pojí i platformně jinak závislé technologie. Trendy v IT systémech se jednoznačně orientují na samostatné služby a jejich skládání.

SOA v IT[editovat | editovat zdroj]

Dokud se psaly desktopové aplikace, bylo to většinou pro určitou platformu, navíc vývojáři byli specializováni na svůj programovací jazyk, ve kterém byla celá aplikace realizována. V této době také vznikl a vyvinul se až do současné podoby objektově orientovaný přístup ve tvorbě IT systémů. Jelikož byl celý systém provozován na jedné platformě, stačilo pro komunikaci s okolím definovat hranice systému pomocí API dané technologie. Na toto API se poté případně napojovaly další systémy či komponenty. V současné době je již situace odlišná. Objektový přístup při návrhu a tvorbě informačních systémů sice zůstal, změnily se ale požadavky na hranice vyvíjených systémů. Dnes systémy, aby se uplatnily na trhu, musí komunikovat i mezi různými verzemi, platformami apod., nestačí tedy definovat API jedné technologie. Pryč je také doba, kdy se vývojáři specializovali na jednu jedinou technologii. Důvodem těchto změn je bezesporu snaha o kompletní pokrytí business procesů informačními systémy, čehož je dosahováno jen kombinací několika technologií. Tyto aspekty a některé další se zapříčinily k prudkému rozvoji SOA přístupu, kdy se hranice systému definují prostřednictvím specifikovaného formátu předávaných dat, které daná služba produkuje či přijímá. V současnosti v drtivé většině případů ke specifikaci přenášených dat dochází prostřednictvím formátu XML, jelikož je velmi dobře strojově čitelný. Dalším důležitým krokem k rozšíření využití SOA bylo zavedení popisu existujících služeb. Každou již existující službu lze vystavit světu pomocí strojem čitelného XML kódu jazyka WSDL (web service description language). Tento jazyk popisuje, jak lze službu volat, jaká data vrací a v jakém formátu.

Komunikace mezi službami probíhá přes SOAP protokol postavený na XML, který pro síťovou komunikaci využívá další protokoly aplikační síťové vrstvy. Nejčastěji HTTP, který bývá povolen na většině firewallů a nasazení je tak méně problematické.

Principy SOA[editovat | editovat zdroj]

Různí autoři mluví o lehce odlišných principech, všechny tyto principy jsou spolu ale konzistentní, jedná se tedy o popis dané situaci více způsoby. Dle http://www.soaprinciples.com existuje 8 hlavních principů.

Standardizovaný kontrakt služby[editovat | editovat zdroj]

Servisní kontrakt poskytované služby je jasně definovaný. Proto je již při návrhu SOA komponenty třeba zvážit technické rozhraní a formát dat, který bude služba přijímat/odesílat. Kontrakt je brán jako slib dané služby svému okolí, co bude poskytovat.

Slabé vazby mezi komponentami[editovat | editovat zdroj]

Vazby mezi jednotlivými komponentami při návrhu SOA mají být co nejtenčí. Tento princip spočívá v tom, že jsou závislosti dodefinovány těsně před použitím a navíc externě, tedy mimo vyvinutou službu, čímž se redukuje závislost kontraktu služby, její implementační logiky a konzumentů.

Princip abstrakce[editovat | editovat zdroj]

Jeho úkolem je co nejvíce skrýt implementační detaily služby/komponenty. Tento princip hraje primární roli také v poskládání složitých systémů a také poskytuje podporu pro předchozí princip volných vazeb. Dobře použitý princip abstrakce zlepšuje granularitu systému a hlavně dovoluje a velmi usnadňuje správu a případné pozdější úpravy systému.

Znovupoužití[editovat | editovat zdroj]

Při návrhu jakékoliv služby či komponenty by se mělo počítat s jejím využitím i jinde, než pro aktuální projekt, čímž se maximalizuje použitelnost vyvíjené části. Pro zajištění tohoto principu je třeba dbát na dobrý architektonický návrh systému.

Nezávislost[editovat | editovat zdroj]

Aby mohla služba zajistit správné fungování, tedy dodržení definovaného kontraktu, musí v sobě obsahovat vnitřní nezávislou logiku pro správu zdrojů, ze kterých čerpá. Tento princip také vyžaduje dodržení určitých pravidel při návrhu, aby bylo možné správné zasazení komponenty do daného implementačního prostředí. V případě SOA se zde mluví o izolaci, normalizaci služeb. Zajištění nezávislost komponenty/služby je důležité pro umožnění principu znovupoužití.

Bezstavovost[editovat | editovat zdroj]

Princip bezstavovosti se začal promítat do návrhů systémů s rozvojem podnikových systémů, které obsluhují velký počet uživatelů. Bezstavovost v tomto případě přímo umožňuje znovupoužití, protože komponenty, které si nepamatují stav lze bez jakýchkoliv inicializačních požadavků okamžitě využít i jinde. Tento princip zajišťuje také větší možnosti škálovatelnosti systému v budoucnu.

Princip identifikovatelnosti[editovat | editovat zdroj]

Tento princip má spíše své ekonomické opodstatnění. Služba, která je lehce identifikovatelná, jakožto je lehce zjistitelný i způsob jejího použití, má obrovskou výhodu na trhu. Takovéto služby přinášejí větší zisk než služby mnohem kvalitnější, ale málo využívané díky jejich nepřístupnosti široké veřejnosti. Identifikovatelnost v SOA je zajištěna WSDL jazykem.

Princip skládání[editovat | editovat zdroj]

V SOA je tímto principem zajištěno možné seskládání jednotlivých služeb a zajištění jejich vzájemné synergie. Kromě již zmiňovaných výhod postupného složení nezávislých komponent/služeb, jde navíc ruku v ruce s odvěkým pravidlem pro řešení komplexních problémů. A sice jejich rozložení na malé, lehce řešitelné podproblémy. Jednotlivá řešení jsou potom seskládána do výsledného systému tak, aby dokázaly zvládnout komplexní problém.

Princip orientace na služby a použití v různých podmínkách[editovat | editovat zdroj]

Princip, který by zde neměl chybět a který zároveň zastřešuje všechny již zmiňované, takže je uveden na devátém místě, přestože bylo v nadpisu avizováno 8 principů. Když se nad tím zamyslíme, zjistíme, že každý z principů z předchozí kapitoly napomáhá k dodržení tohoto posledního, zastřešujících principu. Například definovaný servisní kontrakt zajišťuje znovupoužití služby v různých podmínkách, princip slabých vazeb podporuje orientaci na služby a zajišťuje možnost jejich různých kombinací, které si lze vybrat až v momentě použití služeb atd.

Závěrem[editovat | editovat zdroj]

Lidé pohybující se v IT oboru si jistě povšimnou, že principy, o které se SOA opírá, známe již z učebnic objektově orientovaného programování. Přestože jsou ale principy podobné, jsou realizovány v jiné vrstvě architektury. V servisně orientovaných aplikacích je primárním artefaktem služba, tedy procedurální prvek, který zpracovává či poskytuje data. Data a business logika jsou zde oddělené. Návrhové vzory považované za „best-practices“ v servisně orientovaném návrhu jsou v objektově orientovaném návrhu často považované za anti-vzory a naopak. Jistě stojí za úvahu, zdali jsme se spontánním přechodem k servisně orientované architektuře nevědomky neochudili o nějaký důležitý či užitečný koncept ze světa objektového návrhu.

Příklad[editovat | editovat zdroj]

Pro ilustraci uvádím příklad webové aplikace pro ukládání a úpravu fotografií. Uvažujme případ užití, ve kterém si uživatel zobrazí vybranou fotografii. Na stránce s fotkou má k dispozici kontrolky, pomocí kterých může měnit různé vlastnosti a parametry fotky, například rozměr. Aplikace navržená v intencích SOA paradigmatu bude poskytovat služby pro vyhledání fotografií, pro jejich úpravu, uložení atp. Fotka samotná bude reprezentovaná prostou datovou strukturou bez metod (tzv. anemický objekt). Pokud si uživatel přeje provést nějaké úpravy, aplikace zavolá odpovídající službu, které předá objekt fotografie. Služba vrátí upravený objekt a prezentační vrstva jej zobrazí uživateli. Pokud je uživatel s úpravami spokojen, uloží změny prostřednictvím služby pro ukládání fotografií. Objekt fotografie je po většinu času tzv. odpojený, neboli bez spojení na databázi. Výhody s tím spojené mohou být snadno převáženy komplikovaným a výkonnostně náročným slučováním pozměněného objektu se stávající verzí v databázi během ukládání. Tento problém je obzvlášť citelný v případě rozměrných objektů, jako například právě fotografií. Podívejme se nyní na stejnou aplikaci, tentokrát navrženou v objektovém paradigmatu. Na rozdíl od servisně orientované architektury, kde je primárním artefaktem služba, zde je v centru pozornosti objekt fotografie. Ten neobsahuje pouze prostá data, ale současně s sebou nese také operace pro manipulace s daty (zapouzdření). Požadavek na přeformátování fotografie se nepředává specializované službě, nýbrž se o přeformátování požádá samotný objekt fotografie. Takový design je velmi intuitivní a přirozený, neboť vystihuje naše vrozené vnímání objektů z okolního světa coby autonomní entity. Významným rozdílem je také skutečnost, že objekt je po celou dobu tzv. připojený, neboli v kontaktu s perzistentní vrstvou. Nedochází zde tudíž k onomu komplikovanému a náročnému slučování verzí. Objektový návrh se také elegantněji vypořádává s požadavkem na odlišné zpracování požadavku v závislosti podle typu objektu (polymorfismus). Lze si představit, že změna rozměrů nějaké speciální fotografie, např. fotky do pasu, bude na rozdíl od obyčejné fotografie provádět jakési dodatečné kontroly na povolené rozměry. Využitím dědičnosti (jejíž podpora je součástí programovacího jazyka) lze tohoto chování snadno docílit. V servisně orientovaném návrhu vede řešení takového požadavku k složitému a předpotopnímu řešení pomocí větvení kódu.

Reference[editovat | editovat zdroj]