Service Oriented Architecture

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), a také se pak snáze 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.

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í.

Za službou v SOA stojí většinou poměrně velké množství programového kódu a jakkoliv je princip volání služeb podobný volání metod/procedur v programovacích jazycích, probíhá zde na vyšší úrovni granularity. Např. systém pro správu bankovních účtů může poskytovat několik základních služeb: založení a zrušení účtu, převod peněz z účtu na účet a výběr a uložení peněz. Přestože tyto operace nereprezentují veškerou funkčnost takového systému, jedná se o jeho části, které mohou být důležité nebo zajímavé pro další, spolupracující informační systémy (např. při obchodu s akciemi v burzovním obchodním systému budeme potřebovat pracovat s běžnými účty jednotlivých klientů při nákupu/prodeji akcií). Při složitější spolupráci informačních systémů se mohou zřejmě jednotlivé IS střídavě nacházet v pozici klienta nebo poskytovatele služby. Rozhraní služby (jaké funkčnosti nabízí, jaké parametry tyto funkčnosti potřebují na vstupu a v jaké podobě je vytvářen výstup) může být definováno nějakým obecně respektovaným standardem (aby např. všechny systémy pro správu bankovních účtů byly použitelné s burzovními systémy), nebo je vytvořen pro účely integrace konkrétních IS.

Standardní je ale ve většině případů technologie (přenosové síťové protokoly, způsoby kódování parametrů/výstupů, způsoby definice rozhraní), téměř synonymem pro SOA je dnes pojem Web Services - přestože se jedná jen o jednu možnou implementaci myšlenek SOA do konkrétních technologií. Pro implementaci je nejjednodušší případ, kdy je na servisní rozhraní myšleno již při vytváření informačního systému. Časté je ale i doplňování rozhraní do existujících systémů, buď jako součást servisní podpory nebo v rámci čistě integračních projektů. Nic nevylučuje ani existenci samostatných služeb, přístupných v rámci organizace (představte si třeba službu pro posílání dopisů, která je na základě adresy a textu schopná nechat vytvořit naplněnou obálku se známkou, taková služba není sama o sobě kompletním informačním systémem, přesto zapouzdřuje důležitou funkčnost.

Samotná existence služeb se standardním rozhraním již umožňuje přímou komunikaci mezi klientem a službou, pro její využití ale musí klient dopředu vědět, jakým způsobem se ke službě připojit (tedy že fyzicky běží na serveru s určitou adresou apod.). To jsou informace, které bychom sice měli být schopni v jednotlivých systémech konfigurovat (jinak se prostě jedná o špatně napsané systémy), představte si ale větší firmu s desítkami služeb, umístěných na různých strojích, v systémech, které jsou navzájem propojené – ve chvíli, kdy dojde třeba k drobné reorganizaci podnikové sítě, je nutné měnit konfiguraci řady systémů, starat se případně o jejich restart, aby se změny projevily atp.

Myšlenka existence registru služeb naproti tomu umožňuje mít jedno centrální místo, které umožňuje vyhledávání služeb. K vyhledávání bude typicky docházet podle požadovaného rozhraní (klient si tedy od registru vyžádá službu s určitým rozhraním, tedy nabízející danou funkčnost s určitými parametry a výstupními hodnotami). Nejen, že registr umožní jednodušší stěhování služeb (jediné místo, kde je nutné provést konfiguraci po přestěhování služby na jiný server je právě registr služeb), dokáže také zprostředkovat výběr z více současně běžících implementací požadované služby. V některých případech více instancí služby sice smysl nedává (služby, poskytované IS pro správu bankovních účtů jsou vázané na konkrétní data bankovních účtů a nikdo jiné je tedy poskytovat nemůže), jinde to ale umožňuje zdravou konkurenci. Pokud nás konkurence zajímá jen po čistě technologické stránce, může znamenat rozložení pracovní zátěže mezi více serverů (na kterých daná služba běží) a zabrání tak jejich přetížení. Může se ale jednat také o pravou konkurenci ve smyslu soupeření a zákazníka/klienta. K tomu slouží další zajímavá vlastnost registrů služeb – službě je kromě jejího rozhraní možné při registraci přidělit ještě libovolné atributy, ty mohou zahrnovat informace o kvalitě služby (rychlost, spolehlivost) nebo její ceně. Klient pak při vyhledávání služby může preferovat některá kritéria v závislosti na aktuální situaci (někdy potřebuje rychlou službu za každou cenu, jindy raději využije méně spolehlivou službu zdarma), stejné rozhraní mezi všemi implementacemi zajistí, že po vlastním vyhledání služby je komunikace s ní vždy totožná.

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é.

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 https://web.archive.org/web/20070709123055/http://www.soaprinciples.com/ existuje 8 hlavních principů.

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.

Pro ilustraci lze uvést 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.

• Zbyněk Šlajchrt
• Erl, T. SOA Principles (přístup 16. 11. 2011)
• Managementmania (přístup 20. 12. 2011)
• Pravda o SOA (přístup 9. 11. 2011)

• He, Hao: What Is Service-Oriented Architecture, xml.com; O'Reilly Media, Inc; 30. září 2003. Navštíveno 2017-05-29.

• Obrázky, zvuky či videa k tématu Service Oriented Architecture na Wikimedia Commons