POD KONTROLOU
Vše co potřebujete ke správě, řízení a vizualizaci servisně orientovaných aplikací
PODNIKOVÉ APLIKACE
POD KONTROLOU
Obsah
Čeho i Vy můžete dosáhnout? 3
Česká pojišťovna, a.s. 3
Státní ústav pro kontrolu léčiv 3
SOA jako nástroj strategie byznysu 4
Podpora ze strany vedení společnosti 5
Definice pojmu 5
Nástin životního cyklu služeb 6
SOA jako nástroj strategie byznysu 7
Fáze governance SOA 8
Předprodukční fáze 8
Vytvoření datového modelu SOA 8
Správa kontraktů a předprodukčních politik 9
Správa a poskytování informací 9
UDDI registry 9
Produkční fáze 10
Definice a správa přístupových bodů 10
Autodiscovery, autokorelace a vizualizace síťové mapy volání služeb 10
Vyhodnocování měření a vynucování provozních politik SLA 10
Ideální systém pro správu a řízení provozu SOA 11
Neinvazivnost – cesta k rychlému nasazení 11
Jednoduché otázky – složité odpovědi 12
Automatické zjišťování služeb 12
Zpětná vazba do repozitory SOA 14
Automatické zjišťování konzumentů 15
Automatická korelace volání – síťová mapa volání služeb 16
Eliminace podezřelých poskytovatelů 16
Eliminace podezřelých konzumentů 17
Bezpečnostní politiky 17
Výstrahy a varování 18
SOA governance jako služba 19
Vizualizace SOA 20
Vizualizace SOA + monitorovací politiky SLA 20
Vizualizace SOA + monitorovací politiky SLA + vynucování politik SLA 21
Slovníček pojmů 22
Zdroje 23
O autorovi 23
Čeho i Vy můžete dosáhnout?
Česká pojišťovna, a.s.
Rychlejší a efektivnější dodávání IT služeb koncovým uživatelů.
Snížení počtu incidentů proaktivním přístupem monitorování a vyhodnocováním politik SLA. Rychlejší reakce na incident a rychlejší dohledání příčin potíží (z hodin a dnů na minuty).
„Vidíme dokonce více, než jsme očekávali”, vrchní ředitel provozu IT Xxxxx Xxxxxxxxxx
„Nyní přesně víme, co a proč se v IT infrastruktuře skutečně děje a můžeme tak efektivněji dodávat služby, které společnost potřebuje a požaduje”, ředitel odboru návrhu a dodávky služeb provozu IT Xxxx Xxxxxx
Státní ústav pro kontrolu léčiv
Zvýšení bezpečnosti dat a zabezpečení k jejich přístupu. Minimální pracnost při nasazování a konfigurování nových služeb.
Grafické znázornění komunikace klientů end-to-end a to jak v reálném čase, tak v jejich historii s možností zobrazení až na volanou operaci.
Snížení počtu incidentů přibližně o polovinu proaktivním přístupem monitorování a vyhodnoco- vání politik SLA.
„Actional Intermediary je spolehlivá technologie urychlující proces návrhu, vývoje a nasazení nových služeb a zároveň chránící naše koncové byznys aplikace před případnými mimořádnými událostmi”, PharmDr. Xxxxxx Xxxxx, ředitel SÚKL.
SOA jako nástroj strategie byznysu
Pokud vaše podnikání vykazuje některé z níže uvedených rysů a nevíte přesně, jak tyto rysy podpořit výhodami plynoucími ze servisně orientované architektury (SOA), jste ideálním čte- nářem této brožury Vy nebo některý z vašich kolegů v rolích IT ředitel, vedoucí provozu IT, vedoucí vývoje SW, podnikový softwarový nebo integrační architekt.
Obchodní procesy se rychle mění, na což IT nestačí reagovat.
Uživatelé – typicky ti ve styku se zákazníky – potřebují různá uživatelská rozhraní ke stejným obchodním aplikacím např. chytrý telefon, tablet PC, běžný monitor atd.
Část obchodních procesů se odehrává v reálném čase, což nepodporují současné způsoby monitorování provozu aplikací, reportování ani způsoby řešení incidentů.
Incidentům v IT ani v byznysu se nepředchází, řeší se až když nastanou. Příčinu incidentů dohledáváte pracně a zdlouhavě.
Integrační procesy natož procesy v byznysu nejsou vizualizovány, takže řídíte něco a myslíte si, že víte co.
Vaše IT má být plně nebo i jen částečně v souladu s ITIL respektive chcete poskytovat IT byz- nysu poskytovat jako službu.
Potřebujete provést konsolidaci aplikací, jejich žurnálů nebo datový zdrojů.
Potřebujete zvýšit bezpečnost a zabezpečení komunikaci s klienty, zákazníky, partnery nebo i interními uživateli.
Potřebujete tuto komunikaci řídit obchodními nebo i technickými pravidly.
Uvažujete o měření a vyhodnocování transakcí v IT nebo i v byznysu způsobem end-to-end, ale nevíte, jak jej rychle a efektivně zavést.
Ideálním nástrojem pro řešení výše uvedených oblastí je servisně orientovaná architektura (SOA). Pokud s ní nemáte zatím žádné zkušenosti, jsme připraveni vám zpracovat úvodní studii prove- ditelnosti. Pokud se SOA již zkušenosti máte, můžeme vám poradit s vybranými oblasti jako je např. vizualizace SOA, nasazení SLA politik, nebo jak v reálném čase poskytovat vašemu byznysu informace o vašem podnikání. Naším společným cílem je vybudování nebo se alespoň přiblížení se ideálnímu modelu SOA v podobě referenčního modelu jak nastiňuje obrázek 1.
Předpokladem využití tohoto modelu však je provedení integrace podnikových aplikací. Na inte- graci aplikací je možné pohlížet jako na základní stavební vrstvu, nad kterou je SOA budována. I v této oblasti máme mnohaleté zkušenosti a dokážeme navrhnout a realizovat optimální řešení servisně orientované integrace založené na využití podnikové sběrnice služeb Sonic ESB.
Při postupném budování SOA bývá tématem častých diskuzí, kde a jak služby vystavovat, jak tyto služby zabezpečit a jak uplatňovat politiky SLA. Z pohledu stability a bezpečnosti aplikačního
Obr. 1 | Referenční model servisně orientované architektury společnosti GALEOS.
provozu by bylo nebezpečné, kdyby se byznys služby – tedy zdrojové služby v aplikacích – volaly konzumenty přímo. Pro volání byznys služeb se proto využívá některý z middlewarů (ESB, přístu- pová brána), na kterém se definuje přístupový bod (URL) a vystaví se pouze rozhraní dané byznys služby. Na tomto bodě se také aktivují politiky SLA. Je to bod nacházející se nejblíže ke konzu- mentům a sledovat provoz SOA je nutné především z jejich pohledu.
Podpora ze strany vedení společnosti
SOA v podnicích zpravidla reprezentuje jen část IT architektury. Z pohledu byznysu zpravidla tu stěžejní. Proto by skupina činností zajišťující její správu, řízení, vizualizaci, reporting a systém varo- vání (alerting), měla mít stejně silnou podporu vedení a jasný sponzoring ze strany byznysu, jako ostatní klíčové podnikové iniciativy. Jinak je odsouzena k nezdaru a deziluzi všech zúčastněných.
Definice pojmu
Pro termín SOA governance nemáme lepší překlad než uvedeným opisem výše. Pod pojmem SOA governance tedy budeme uvažovat skupinu činností zajišťující správu, řízení, vizualizaci, reporting a systém varování SOA.
Hlavním posláním činností SOA governance je zajištění, aby investice vkládané do budování SOA přinesly očekávané přínosy a efekty a to jak v krátkodobém horizontu, tak během celého jejího životního cyklu. Vaše společnost tedy musí být připravena investovat, a to jak do lidí, tak do softwarových technologií.
Je asi více než zřejmé, že se bez vhodné softwarové technologie neobejdete. Následující text proto bude volně vycházet z technologické řady softwarových produktů Progress Actional a HP Systinet, s kterými má GALEOS, jeho zákazníci a partneři, dlouhodobě dobré zkušenosti.
Činnosti SOA governance jsou realizovány následujícími procesy řízení:
Řízení shody se SOA politikou, pravidly a standardy organizace. Řízení výjimek umožňující je detekovat a v reálném čase zpracovat.
Řízení komunikace zajišťující, aby každý organizační stupeň obdržel informace v požadované formě i obsahu.
Nástin životního cyklu služeb
Obr. 2 | Nástin životního cyklu služeb.
Ústřední komponentou v SOA je služba. Přestože nemusíte od samého počátku budování SOA uvažovat v intencích pokrytí celého životního cyklu služeb, zvolená technologie by měla celý tento cyklus podporovat. Důvod je prostý: Až se dostanete do fáze, kdy budete chtít začít používat další funkcionalitu, nebudete muset tuto technologii měnit.
V období, kdy podniky architekturu SOA navrhovaly, vyvíjely a postupně nasazovaly, se řídicí a kontrolní mechanizmy soustřeďovaly zpravidla pouze na samotnou tvorbu služeb, tvorbu WSDL a testování služeb.
Naproti tomu dnes, kdy jsou SOA služby v řadě organizací již produkčně využívány, architekti zjišťují, že nejkritičtější problémy spojené se správou a řízením se týkají právě provozu. Příliš mno- ho implementací SOA zkrátka nepracuje podle očekávání, podle toho, jak byly navrženy a jaká očekávání byla nastavena. Chybí reálná zpětná vazba, jak jsou služby skutečně nasazeny a využí- vány, dochází k častým výpadkům jednotlivých služeb, selhávají i celé byznys procesy a objevují se rizika spojená s nedostatečným zajištěním souladu s firemními nebo legislativními pravidly.
Obr. 3 | Šest pilířů SOA. Zatímco první čtyři pilíře bývají běžné, zbylé dva jsou výjimkou.
Fáze governance SOA
Jak nastiňuje obrázek 2 činnosti governance SOA můžeme rozdělit na dvě základní fáze a níže uvedené činnosti:
Předprodukční fáze (design time) Vytvoření datového modelu SOA
Správa kontraktů a předprodukčních politik Správa a poskytování informací
UDDI registry Produkční fáze (run time)
Definice a správa přístupových bodů
Autodiscovery, autokorelace a vizualizace síťové mapy volání služeb Vyhodnocování měření a vynucování provozních politik SLA
Předprodukční fáze
Vytvoření datového modelu SOA
To co platí pro běžné aplikace, zde platí dvojnásob: dobře navržený datový model je klíčovým stavebním kamenem celé servisní architektury. Musí umožňovat uchovávat jak všechna data, tak i metadata o službách. Kromě obvyklých údajů, jako kdo je vlastníkem služby, jakými procesy (životním cyklem) musí procházet, kde má být služba umístěna, jakou má úroveň zabezpečení, jaký soubor pravidel je na ní kde aplikován apod., je nutné uchovávat i informace o vzájemných vztazích a závislostech služby a jejích konzumentů. Tyto informace slouží pro analýzu základních příčin problémů, pro kapacitní plánování, pro verzování služby a plánování údržby.
Přestože SOA governance nástroje nabízejí předpřipravené prototypy datových modelů SOA, bývá nutné je individuálně přizpůsobit každému zákazníkovi, což představuje iterativní proces a schůzky jak s obchodním útvarem tak s pracovníky IT (architekti, integrační tým i vývojáři). Vstu- py do této iterace jsou dále množina požadovaných formálních i neformálních procesů, vertikální a horizontální návrh aplikační architektury, existující data pro iniciální import apod.
Správa kontraktů a předprodukčních politik
Zde se definují a povolují vazby mezi konzumenty a poskytovateli a nastavují se očekávaná cho- vání služby v podobě tzv. cílů služby, viz pojem Service Level Objectives ve slovníčku. Pokud takový kontrakt není definován, konzument by neměl mít možnost využít danou službou.
Správa a poskytování informací
Úlohou těchto činností je doručení odpovídajících informací všem vlastníkům v podobě pro ně vhodné. Je zřejmé, že pracovníci v IT mají na infrastrukturu SOA jiný pohled s odlišnou mírou abstrakce a požadavků než vedoucí pracovníci nebo pracovníci obchodu. Každé této skupině je nutné prezentovat potřebné informace v pro ně odpovídajícím obsahu i formě.
UDDI registry
Tato úložiště představují vhodný doplněk k repozitory SOA. Uchovávají jen část dat a metadat o službách. UDDI registry obsahují mechanizmus pro klasifikaci, katalogizaci a dynamické ná- hledy na služby. Takto kategorizované služby pak mohou zjišťovat a využívat přes definované rozhraní i jiné aplikace. Typicky jde o vývojová prostředí, což přispívá k větší produktivitě vývojářů, lepšímu zviditelnění služeb a jejich větší znovupoužitelnosti jak v rámci organizace tak mezi nimi.
Mezi repozitory SOA a UDDI registry dochází v poslední době k částečnému překryvu funkciona- lity. Rozdíl je v úhlu pohledu na služby [JOS]. Repozitory SOA nabízejí byznys pohled na služby nezávislý na implementaci (procesy, kontrakty, run-time SLA atp.). Naproti tomu UDDI registry poskytují technický pohled na služby popisující technické detaily rozhraní a veškeré další infor- mace, které je nutné znát, aby se mohla služba využít (URL, WSDL, přístupová oprávnění).
Jiným úhlem pohledu poskytuje [HBBK] nabízející rozlišení dle způsobu promítání změn do da- ného úložiště. Zatímco repository SOA slouží k uchování statických informací o službách v prů- běhu celého životního cyklu a to včetně zdrojových kódů všech verzí služby, UDDI registry naproti tomu poskytují dynamický pohled na služby – kde je služba v dané verzi právě teď fyzicky umís- těna a dostupná.
Produkční fáze
Definice a správa přístupových bodů
Pokud jsou správně nastaveny kroky životního cyklu služby, jsou přístupové body (access po- ints, endpoints) a jejich konfigurace automaticky generovány z repozitory SOA. Tím je elegantně zajištěno, že všechny nasazené služby a jejich konzumenti odpovídají předem definovaným po- litikám a kontraktům. Pokud repozitory SOA nevyužíváte, je nutné přístupové body konfigurovat manuálně.
Autodiscovery, autokorelace a vizualizace síťové mapy volání služeb
Skupina činností automaticky zajišťující detekci a vizualizaci SOA v reálném čase resp., zjiš- ťující, jaké služby/operace se v provozu právě nacházejí. Pokud je zjištěna „podezřelá“ (rogue) služba/operace, např. ta která nemá validní kontrakt nebo nemá kontrakt definován vůbec, není této službě např. umožněna komunikace.
Zde doslova platí: „Co nevidím, nemůžu účinně spravovat, natož řídit“. Vizualizace veškeré komunikace služeb spolu se systematickým kontinuálním monitorováním a zjišťování příčin po- rušení SLA pravidel umožňuje zavést režim, v kterém jsou organizace schopné tato porušení okamžitě v reálném čase vidět, zjistit jejich příčinu a vhodně na ni reagovat. Koordinací řízením vývoje a řízením provozu tak mohou organizace vybudovat prvotřídní ucelené řízení celého život- ního cyklu SOA, kde každá její část ve správnou dobu splní přesně svoji roli.
Vyhodnocování měření a vynucování provozních politik SLA
Skupina činností automaticky zajišťující v reálném čase:
Sběr a vyhodnocování parametrů komunikace, jako jsou např. počet volání, doba odezvy, veli- kost zpráv, velikost průtoku dat, chyby nebo výjimky apod.
Vynucování provozních politik SLA, jako např. „pokud počet volání dané služby za posledních 5 mi- nut je větší než 1 000, potom nepřijímej další volání, dokud počet volání neklesne pod tuto hranici“.
Při vynucování politik SLA je možné reagovat na příchozí události a to jak z pohledu dynamické re- akce IT (služba požadavek odmítne z důvodů velikosti zprávy), tak z pohledu dynamické reakce byznysu (objednávka odmítnuta – chybí např. IČO).
Ideální systém pro správu a řízení provozu SOA
Někteří zákazníci aplikují činnosti SOA governance pouze v rámci produkční fáze bez využití re- pozitory SOA. Je to samozřejmě možné, ale jen do určitého počtu služeb a operací, jen do určité míry složitosti SOA, dané zejména počtem vazeb mezi konzumenty a poskytovateli služeb.
Faktem je, že většina zákazníků repository nebo registry nepoužívá. Proto v následujícím textu uvedeme činnosti spadající zejména do produkční fáze a nastíníme vlastnosti ideálního systému pro runtime governance SOA.
Neinvazivnost – cesta k rychlému nasazení
Jedna z klíčových vlastností systému pro správu a řízení provozu SOA je automatické zjišťování, které služby a kteří konzumenti se nacházejí v daném prostředí (produkční, testovací, vývojové). Pro tuto detekci je zpravidla využíván neinvazivní software, založený na softwarových agentech. Neinvazivnost agentů spočívá v tom, že není nutné zasahovat do zdrojových kódů stávajících aplikací pro to, aby se činnosti governance SOA mohly v plném rozsahu realizovat.
Obr. 4 | Systém pro správu a řízení SOA by měl nabízet různé pohledy pro různé uživatele.
Softwaroví agenti sledují na dané platformě provoz mezi jednotlivými službami (příchozí a od- chozí volání, JMS messaging apod.), přičemž tyto údaje jsou schopni zobrazit z pohledu jak infrastrukturního, tak byznysového, jak nastiňuje obrázek níže. Tato data zároveň v reálném čase vstupují do politik SLA a slouží k jejich prosazování. Znamená to významný posun vpřed jak v oblasti runtime governance SOA, tak i výrazný pokrok v omezování rizik spojovaných s imple- mentacemi SOA. Tam, kde architekti byli dříve schopni testovat shodu s pravidly jen u některých služeb, mohou nyní odpovědně prohlásit: „Neexistuje žádná služba v provozním prostředí, která není ve shodě s našimi pravidly“.
Ideální systém pro správu a řízení provozu SOA by měl:
Nabízet více obchodních modelů k jeho realizaci (investice, SaaS, …). Být neinvazivní vůči aplikacím.
Vizualizovat reálný obraz integračních i obchodních procesů. Automatizovaně zjišťovat poskytovatele a konzumenty služeb. Nabízet rozhraní pro integraci s registry/úložišti třetích stran. Automatizovaně mapovat toky zpráv a sledovat vazby mezi službami. Detekovat a eliminovat podezřelé služby.
Oddělovat politiky od služeb. Politiky proaktivně prosazovat.
Umožňovat měnit politiky nezávisle na změnách služeb a integračních procesů nebo procesů v byznysu a naopak.
Systém runtime governance SOA by přitom neměl být omezen pouze na webové služby a pro- xxxxxx HTTP/S. Podporovány musí být jak dvě dnes stěžejní platformy J2EE a .NET, tak a i další protokoly, které se běžně používají, jako jsou např. REST, JMS, RMI, XXX, JDBC apod.
Jednoduché otázky – složité odpovědi
Pro správu a řízení provozu SOA je důležitý její okamžitý stav a zajištění očekávaného poskytová- ní funkcionality a očekávaného chování jednotlivých služeb. Je nezbytné vědět nejenom to, co se děje v celé SOA právě teď, ale i to, co se stalo v minulosti.
Automatické zjišťování služeb
Cílem automatického zjišťování v provozním prostředí je nejenom detekce toho, co se děje v ar- chitektuře SOA s vědomím organizace, ale zejména toho, co se děje bez vědomí organizace.
Automatické zjišťování objektů, vazeb a událostí by přitom nemělo vyžadovat manuální konfigura- ci a korelaci. Ideálně by se mělo jednat o „samosběrné a samoučící se“ mechanizmy. Jedině tak dostanou architekti reálnou zpětnou vazbu o SOA „tak jak ve skutečnosti vypadá“ a ne „tak jak ji někdo navrhl a myslí se, že vypadá“. Je tedy až překvapivé, jak obtížné může být zjišťování následujících odpovědí:
Které všechny služby jsou v ostrém provozu?
To, že se služba neobjevuje v registrech, neznamená, že není používána.
Které všechny služby jsou skutečně využívané?
Administrátoři vidí, že systém nebo rozhraní pracuje, ale bez vhodných nástrojů nemají šanci zjistit, kam zprávy odcházejí.
Kdo jsou konzumenti dané služby?
I když je přístup ke službě zabezpečený, nedá se zjistit, kteří konzumenti danou službu právě vy- užívají bez pracného prověřování každé transakce či zprávy a procházení logovacích souborů. Existuje deset konzumentů dané služby.
Jaký vliv bude mít přidání jedenáctého?
Průměrná doba odezvy služby je xxx ms.
Jsou skutečně všichni konzumenti této služby spokojeni?
Službu chceme zrušit, změnit, verzovat nebo vypnout.
Existuje vůbec někdo, kdo ji ještě využívá? Kdy naposledy to bylo?
Stupeň poskytnutého detailu je vlastnost odlišující řadu technologií SOA governance. Některé technologie poskytují přehled pouze na úrovni uzlů (serverů) a služeb, což není dostatečné. Po- skytnutí detailu na úrovni provozu služby a všech jejích operací pak výrazně obohacuje funkcio- nalitu takového produktu (viz obr. 5 a 6).
Obr. 5 | Přehled o SOA pouze na úrovni uzlů – příliš hrubý pohled.
Obr. 6 | Přehled o SOA na úrovni služeb a jejích operací – ne příliš obvyklý stupeň detailu.
Zpětná vazba do repozitory SOA
Informace zjištěné během provozu služeb mohou být také sdíleny a přenášeny do repozitory SOA. Architekti, integrační tým, vývojáři i pracovníci provozu mohou například využít aktuální statistiky výkonnosti nebo informace o současné úrovni poskytování služeb, které se do SOA úložiště mohou ukládat k jemnějšímu doladění SLA. Reálná zpětná vazba umožní zlepšit rozho- dovací proces, zvýšit návratnost SOA a uspořit náklady spojené se správou a využíváním služeb. Důležité mohou být i sekundární efekty, jako jsou zlepšená morálka uživatelů i pracovníků v IT, (všichni vědí, že je využívání služeb monitorováno, vyhodnocováno a účtováno v reálném čase, proto se všichni snaží dodržovat nastavená pravidla).
Automatické zjišťování konzumentů
Organizace obvykle nemívají možnost, jak se dozvědět, kteří konzumenti právě teď využívají nebo využívali jaké služby, jakých SLA bylo při této konzumaci dosaženo, nebo zda k určité službě ne- přistupují neautorizovaní uživatelé. Pokud navíc organizace nevědí, zda služba nebo konzument vůbec existují, těžko na ně mohou aplikovat podnikové a bezpečnostní politiky.
Na stejný problém se může podívat i z druhého konce – z pohledu politik SLA. Neexistuje jed- noduchý způsob, jak zjistit, zda úroveň poskytování služeb, které konzumenti skutečně dostávají, odpovídá sjednané úrovni. Nástroje pro runtime governance řeší i tyto problémy, protože umožňu- jí IT oddělení sledovat a účtovat využívané služby. Navíc poskytují náhled do široké škály dalších problémů spojených se správou SOA, jako jsou např.:
Implementovali jsme novou službu, převedli ji do ostrého provozu a vývojový server chceme vypnout. Existuje někdo, kdo jej ještě využívá?
Vytvořili jsme novou službu, ale nejsme si jisti, jak je užitečná. Chceme zjistit, kdo, kdy, jak a k čemu ji v organizaci využívá.
Chci zjistit, jaké vhodné služby mně poskytovatel nabízí a chci kromě samotného popisu zjistit i základní technické parametry (WSDL, povolená velikost a četnost zpráv, zabezpečení apod.).
Rád bych užíval určitou službu, ale nejsem si jist, jakou má dobu odezvy, přičemž právě doba odezvy je pro mě nejdůležitější. Vím, co o službě říká její poskytovatel, ale dostanu skutečně slibovaný výkon?
Využívám službu z jiné části organizace, kde za používání chtějí fakturovat. Vím, že jiní tuto službu využívají zdarma, tak proč bych měl platit právě já?
Nakolik daný poskytovatel služeb dodržuje politiky SLA? Mohu věřit jeho schopnostem plá- nování?
Obr. 7 | Propojení předprodukční a produkční fáze životního cyklu služeb pomocí repozitory HP SOA Systinet a SOA runtime governance Progress Actional. Registry a repository je možné využít i od jiných výrobců např. Oracle AquaLogic Enterprise Repository nebo Software AG CentraSite Governance Edition.
Automatická korelace volání – síťová mapa volání služeb
Systém governance SOA by měl být schopen automaticky svazovat volání konzumentů a služeb a vytvářet tak síťovou mapu. Tato mapa pak může být použita nejenom pro vizualizaci řetězce vo- lání, ale i pro sledování integračních nebo i obchodních procesů. Toto sledování umožňuje aktivo- vat příslušné politiky v případě, kdy dojde k určité události nebo naopak k určité události nedojde. Mapování komunikačních toků v ideálním případě vytváří interaktivní topologickou mapu, která ukazuje, kudy (mezi kterými službami nebo systémy) zprávy fyzicky skutečně proudí. Tyto proudy by se přitom měly zjišťovat zcela automaticky, kvůli jejich průkaznosti.
Pokud nástroje pro runtime governance vědí o vzájemné vazbě dvou služeb a jejich SLA, mohou generovat upozornění v případě, že jedna z nich není v provozu. To může výrazně zkrátit případný výpadek a omezit důsledky porušení SLA. Mapování toku volání je důležité i z hlediska způsobu, jakým jsou aplikovány politiky SLA. Je pak možné automaticky vyhodnotit, kde na cestě po smě- ru či proti směru volání dochází k problémům.
Obr. 8 | Automatická detekce podezřelých služeb vyžaduje využití repozitory SOA.
Eliminace podezřelých poskytovatelů
Podezřelá a tím potenciálně nebezpečná služba (rogue service) je každá služba, která neprošla definovaným životním cyklem a byla např. vystavena manuálně administrátorem. Taková služba je vždy rizikem pro životaschopnost SOA, neboť:
Může zveřejnit citlivá data a vystavit tak společnost riziku. Může využívat kapacitu systému bez možnosti účtování zdrojů.
Může se vyhnout dodržování zákonů nebo podnikových předpisů.
Snižuje motivaci dodržovat SLA runtime politiky SLA, protože tyto politiky na ni nelze uplatnit.
Odhalení podezřelé služby by ideálně mělo opět probíhat samočinně a to nejlépe v reálném čase pomocí automatické funkce pro zjišťování služeb (autodiscovery). Nezbytným předpokladem pro její odhalení je využití informací z registrů nebo repozitory SOA. Tato úložiště definují, zda se v daném prostředí vůbec může taková služba nacházet. Ideální nástroj pro správu a řízení pro- vozu SOA pak dokáže takovou službu okamžitě detekovat a eliminovat do doby, než jsou na ni uplatněna příslušná pravidla a politiky.
Eliminace podezřelých konzumentů
Podezřelý je takový konzument, který nemá pro danou službu definovaný kontrakt. Takový konzu- ment by neměl mít šanci se službou komunikovat. Co však dělat, pokud žádné repozitory nemáte?
Řešením může být vytváření černé listiny konzumentů. Systém governance SOA při každém dotazu konzumenta zkontroluje, zda právě on není na černém seznamu. Pokud ano, zabrání mu v další komunikaci. Černá listina bývá zpravidla vytvářena dynamicky na základě chování konzumentů v ur- čitém časovém okně. Pokud všichni dodržují politiky SLA, nikdo na černé listině není. Jakmile ně- který konzument (úmyslně nebo neúmyslně) poruší parametry SLA (velikost zprávy, procento chyb, četnost volání atp.), může být automaticky dán na černou listinu do doby, než své chování změní.
Bezpečnostní politiky
Vzhledem k tomu, že nástroje SOA governance umožňují automaticky iniciovat příslušnou poli- tiku bez toho, aby byla provázána s určitou službou, může být taková politika široce aplikována na všechny služby, skupiny služeb nebo servery v celé síti. A to včetně právě zjištěných podezře- lých služeb nebo služeb, které teprve budou do infrastruktury přidány někdy později. Například bezpečnostní pravidlo „zákaznická data musí být šifrována“ je automaticky aplikováno na každou zjištěnou nebezpečnou službu, čímž se chrání jak zákazník, tak samotná společnost. Kdokoliv, kdo tuto službu provozuje, pak automaticky zdědí základní rámec governance, kterému musí daná služba odpovídat a soulad s těmito politikami se tak nebude zajišťovat až dodatečně.
Výstrahy a varování
Každý konzument může mít nastaveny odlišné SLA, využívat jiné služby a být jinak ošetřován. Nástroj pro správu a řízení provozu SOA by měl umožňovat detailní pohled na jednotlivé konzu-
menty a na to, s jakou rychlostí či dobou odezvy pro ně příslušné služby pracují. SLA by měla být definována dvouprahově: Například měkký práh pro 80% porušení a tvrdý práh pro 100% porušení. Při porušení daného SLA, by systém měl přesně určit, která služba či vazba je za toto porušení odpovědná (například kde dochází k nepřípustným prodlevám a jaká je jejich příčina).
Obr. 9 | Jen na pár kliknutí lze dohledat zdroj příčiny potíží – tedy kde dotaz posbíral oněch 32.1 sec.
Důsledné oddělení politik SLA od služeb
Politiky SLA se obvykle mění nezávisle na vývoji, nasazení a změnách aplikací. Je proto vhodné zajistit, aby se zavádění a prosazování politik mohlo uskutečňovat zcela odděleně. Kvalitní ná- stroje pro runtime governance poskytují potřebné funkce i pro tento úkol. Vizualizace a kontrola integračních procesů usnadňuje poskytování informací o těchto politikách a umožňuje provádět jejich změny v reálném čase.
Důsledné uplatňování zásad správy a řízení provozu SOA vede v konečném důsledku k tomu, že podnikový systém SOA může v ostrém provozu dynamicky reagovat na podnikatelské příležitosti i na problémy IT, což se příznivě projeví na celkových hospodářských výsledcích celé organizace.
SOA governance jako služba
Jak a kde se SOA governance začít? Využít nebo nevyužít repozitory SOA? Potřebuji i UDDI registry? Musím spravovat a řídit opravdu všechny služby v provozu? Jak aplikovat pravidla SLA na externí komunikaci? Máte-li tyto a další otázky, nabízíme vám kromě obvyklé dodávky softwa- rových licencí a implementačních služeb velmi rychlý start v podobě dodání governance SOA jako služby.
Obr. 10 | Koncept SOA governance jako služba.
SOA governance nabízíme jako službu ve třech variantách, které se liší šíří výstupů:
1. Vizualizace SOA
2. Vizualizace SOA + monitorovací politiky SLA
3. Vizualizace SOA + monitorovací politiky SLA + vynucování politik SLA
Vizualizace SOA
Výstupem této služby je síťová mapa volání služeb tak, jak ji nastiňují obrázky 5 a 6. Mapa je vy- tvářena na základě funkcí autodiscovery a autokorelace volání služeb. Mapa poskytuje detailní přehled čtyř úrovní volání. Volání mezi jednotlivými servery, skupinou služeb, službami a opera- cemi.
Mapa je interaktivní a umožňuje traverzovat jed- notlivá volání (posunovat se v čase po směru nebo proti směru volání). Pro jednotlivé úrovně jsou k dispozici statistiky: počet volání, doba ode- zvy, velikost zprávy, objem dat, datový průtok, chy- by a výjimky.
V rámci síťové mapy volání služeb je možné se časovým posuvníkem pohybovat jak v reálném čase, tak libovolně v minulosti.
Předpokladem využití této varianty služby je nein- vazivní nasazení softwarových agentů automatic- ky detekujících služby a jejich operace.
Vizualizace SOA + monitorovací politiky SLA
Obr. 11 | K dispozici jsou základní statistiky pro jednotlivé úrovně volání: mezi servery, sku- pinou služeb, službami nebo operacemi.
Výstupem této služby je kromě výstupů „Vizualiza- ce SOA“ i základní sada politik SLA, které vybrané služby monitorují. V případě porušení politiky je toto porušení detekováno a zaznamenáno a je generována výstraha nebo varování (viz dvou- prahové nastavení politik v podkapitole výstraha a varování). Kromě zachycení výskytu tohoto in- cidentu je ad-hoc vygenerována síťová mapa pro toto volání. Dle potřeby je možné toto volání a jeho odpověď auditovat včetně těla zprávy.
Obr. 12 | Detekce porušení politiky SLA a ad-hoc vygenerovaná mapa vztahující se k tomuto porušení.
Vizualizace SOA + monitorovací politiky SLA + vynucování politik SLA
Výstupem této služby je kromě výstupů „Vizualizace SOA + monitorovací politiky SLA“ i možnost proaktivního vynucování politik SLA a řízení a zabezpečení přístupů ke službám. Předpokladem využití této varianty je využití bezpečnostní brány pro volání služeb (WS, REST, JMS) Actional Intermediary.
Tato bezpečnostní brána bezezbytku řeší veškeré úlohy související s autentizací, autorizací, šifro- váním komunikačního kanálu nebo i obsahu zasílané zprávy, elektronického podepisování resp. PKI nebo SAML.
Obr. 13 | Pro vynucování politik SLA musejí volání procházet bezpečnostní bránou Actional Intermediary.
Slovníček pojmů
Byznys služba, ně- kdy i jako funkční služba.
Endpoint, někdy i jako přístupový bod
Zdrojový poskytovatel požadované funkcionality, sídlící zpravidla přímo v aplikaci na aplikačním serveru.
Přístupový bod představuje konkrétní URL pro přístup k dané službě. V rámci životního cyklu se může služba nacházet v různých prostředích: Vývojové, tes- tovací, produkční apod. V každém prostředí má služba jiný endpoint.
ESB Enterprise Service Bus. Podniková sběrnice služeb – typ integrační middle- waru sloužící i pro vystavování (proxy) služeb.
Kontrakt Definice duálního vztahu mezi konzumentem a poskytovatelem. Konzument Osoba nebo organizační jednotka, využívající danou službu.
Podezřelá služba Každá služba, která neprošla definovaným životním cyklem.
Politiky SOA Souhrn předprodukčních a produkčních očekávaných chování a vlastnos- tí (pravidel) dané služby, uplatňovaných v různých fázích jejího životního cyklu. Tato očekávání se mohou vztahovat jak k formě volání dané služby, (pravidla pro dobu odezvy, povolenou velikost a četnost zpráv, pro výjimky), mohou se vztahovat k zabezpečení služby (šifrování, přístup dle rolí, audi- tování činnosti služby), tak se mohou vztahovat k práci s obsahem zpráv, například pro určitý typ zprávy mě zajímá sledovat a v reálném čase sčítat určité hodnoty ze zasílané zprávy.
Poskytovatel Osoba nebo organizační jednotka, zodpovědná za kontrakty a politiky svá- zané s danou službou, které konzument chce využít.
Proxy služba Rozhraní pro byznys službu vystavené typicky na ESB.
SAML Security Assertion Markup Language – standard založený na XML posky- tující mechanismus pro výměnu autentizačních a autorizačních dat mezi službami.
SLA / SLO Service Level Agreement, Service Level Objectives – Smlouvy o úrovni po- skytovaní služeb. Každý poskytovatel je spojen s určitou množinou pravidel ovlivňujících jak jeho chování, tak chování jeho konzumentů.
Služba Smluvní interface do softwarové logiky.
URL Uniform Resource Locator – jednotný lokátor zdrojů – řetězec znaků s de- finovanou strukturou, který slouží k přesnému určení umístění zdrojů infor- mací např. služby.
WSDL Web Services Description Language – standard pro popis rozhraní webové služby.
Zdroje
Produktové materiály společností Progress Software a HP.
[JOS] Xxxxxxx X. Xxxxxxxx, SOA in Practice, X’Xxxxxx, 2007, ISBN 0-596-52955-4.
[HBBK] Xxxxxx Xxxxxxx, Xxxxx Xxxxx, Xxxxx Xxxxxxx, Xxxxxx Xxxxxxx, Service Oriented Archi- tecture For Dummies, Wiley Publishing, 2007, ISBN: 0-470-05435-2.
O autorovi
Xxxxxxxx Xxxxxx vystudoval katedru ASŘ na VŠE. Pracoval v Soft- ware602 a poté více než 12 let v pražské pobočce Progress Software,. Nyní je zodpovědný za presales a vedení projektů ve společnosti GALEOS a.s, která je mimo jiné distributorem technologií Progress Software a HP. Má zkušenosti s návrhem, nasazením a provozem servisně orientovaných projektů (servis- ně orientované integrace podnikových aplikací, SOA governan- ce) a to jak v ČR, tak v zahraničí. Příležitostně publikuje články na témata z oblasti SOA/SOI, příležitostně přednáší na domá- cích i mezinárodních konferencích, katedře IT VŠE a MFF UK.
GALEOS a.s.
Xxxxxxxxx 000/00 x 000 00 Xxxxx 0 | Tel.: x000 000 000 000 Email: xxxx@xxxxxx.xx | xxx.xxxxxx.xx | xxx.xxxxxx.xx Code: CZSG-0611-R2.5