- Přehledy IS
- APS (20)
- BPM - procesní řízení (22)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (33)
- CRM (51)
- DMS/ECM - správa dokumentů (20)
- EAM (17)
- Ekonomické systémy (68)
- ERP (79)
- HRM (27)
- ITSM (6)
- MES (32)
- Řízení výroby (36)
- WMS (29)
- Dodavatelé IT slueb a řeení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (39)
- Dodavatelé CRM (33)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (71)
- Informační bezpečnost (50)
- IT řeení pro logistiku (45)
- IT řeení pro stavebnictví (26)
- Řeení pro veřejný a státní sektor (27)
Tematické sekce
ERP systémy
CRM systémy
Plánování a řízení výroby
AI a Business Intelligence
DMS/ECM - Správa dokumentů
HRM/HCM - Řízení lidských zdrojů
EAM/CMMS - Správa majetku a údrby
Účetní a ekonomické systémy
ITSM (ITIL) - Řízení IT
Cloud a virtualizace IT
IT Security
Logistika, řízení skladů, WMS
IT právo
GIS - geografické informační systémy
Projektové řízení
Trendy ICT
E-commerce B2B/B2C
CAD/CAM/CAE/PLM/3D tiskBranové sekce
![]() | |
| Přihlaste se k odběru newsletteru SystemNEWS, který kadý týden přináí výběr článků z oblasti podnikové informatiky | |
![]() | |
Partneři webu
IT SYSTEMS 10/2006 , ITSM (ITIL) - Řízení IT
Řízení SOA v provozním prostředí
Jindřich tumpf
Řízením SOA (SOA governance) se označuje souhrn politik, procesů a vizualizačních nástrojů pro správu volně spojených systémů zaloených na modelu SOA a pro jejich vizualizaci z pohledu IT i byznysu. Ze současné nabídky nástrojů softwarových dodavatelů se dá soudit, e se dosud jedná pravděpodobně o nejméně propracovanou oblast. K pionýrům (Actional, Amberpoint, SOA Software) se postupně připojují i tradiční dodavatelé s rozířenou nabídkou funkcionality stávajících nástrojů pro správu IT infrastruktury (HP OpenView, IBM Tivoly, CA Unicenter).
Mezi hlavní přísliby architektury SOA patří interoperabilita a znovupouitelnost slueb. Oba poadavky se dají plně realizovat pouze při součinnosti vech zainteresovaných sloek. Nepřekvapí proto, e právě díky SOA v minulých letech výrazně vzrostl zájem o governanci, na kterou se začal klást stále větí důraz.
V období, kdy větina společností architekturu SOA vyvíjela a navrhovala, se řídicí a kontrolní mechanismy soustředily na samotnou tvorbu slueb, procesy jejich zavádění či tvorbu WSDL a řízení SOA se zaměřovalo na předprodukční fázi.
Naproti tomu dnes, kdy v mnoha organizacích jsou sluby SOA ji zavedeny do produkčního prostředí, systémoví architekti zjiují, e nejkritičtějí problémy spojené s kontrolou a řízením se týkají právě ostrého provozu. Příli mnoho implementací SOA prostě nepracuje podle očekávání. Dochází k přeruování činnosti jednotlivých slueb, celé podnikové procesy selhávají a objevují se rizika spojená s nedostatečným zajitěním souladu s předpisy a zákony (compliance), která vedou k nákladným prodlevám. Řízení v provozním prostředí (runtime governance) se proto stává kritickou součástí celkové strategie řízení jakékoli organizace.
Znamená to významný posun vpřed v SOA governance i výrazný pokrok v omezování rizik obvykle spojovaných s implementacemi SOA. Tam, kde architekti byli dříve schopni testovat shodu se zákony a vyhlákami jen u některých slueb, mohou nyní odpovědně prohlásit: Neexistuje ádná sluba v provozním prostředí, která není ve shodě s naí politikou.
Moderní řeení pro SOA governance by mělo umoňovat:
Obr. 1: Z celopodnikového hlediska musí být řízení SOA uplatňováno napříč aplikacemi
Strategie runtime governance pro architektury SOA by přitom neměly být omezeny pouze na webové sluby a HTTP provozované na aplikačních serverech zaloených na J2EE a .NET, ale měly by zahrnovat i různé jiné protokoly a platformy, které převaují v reálném světě SOA, jako jsou RMI, EJB, JDBC atd.
Cílem automatického zjiování v provozním prostředí je kromě jiného zjistit i to, co se děje v architektuře SOA bez vědomí organizace, a poskytnout vizuální přehled dostupných slueb a dalích metadat o slubách (politiky, bezpečnostní poadavky, metriky podnikání, smlouvy SLA atd.).
Informace zjitěné během procesu governance mohou být také sdíleny v otevřených registrech nebo úloitích, které umoňují konsolidovaný přístup ke správě metadat slueb. Vývojáři i provoz mohou například vyuít slubu poskytující aktuální statistiky výkonnosti nebo informace o současné úrovni slueb. Lepí informace umoní zlepit rozhodovací proces, zvýit návratnost SOA a uspořit náklady spojené se znovupouitím slueb. Důleité jsou i sekundární výsledky, jako zlepená morálka zaměstnanců, nií náklady na podporu a vyí vyuití technologií v rámci celé organizace.
Velkým problémem můe být zjiování a správa konzumentů slueb. Organizace obvykle nemají ádnou monost jak se dozvědět, kteří konzumenti vyuívají které sluby a jaké úrovně slueb dostávají, ani zda k určité slubě nepřistupují neautorizovaní uivatelé. Navíc pokud organizace nevědí, zda sluba nebo konzument vůbec existují, těko na něj mohou aplikovat podnikové a bezpečnostní politiky.
Stejný problém je i se smlouvami SLA neexistuje způsob, jak zjistit, zda úroveň slueb, které zákazníci skutečně dostávají, odpovídá sjednané úrovni. Nástroje pro runtime governance řeí i tyto problémy, protoe umoňují IT oddělení sledovat a účtovat vyuívané sluby. Navíc poskytují vhled do iroké kály dalích problémů spojených se správou SOA:
Mapování toků vytváří topologickou mapu aplikací, která ukazuje, kudy zprávy fyzicky sítí proudí. Tyto vztahy se přitom zjiují automaticky, take je není potřeba konfigurovat manuálně. Pokud nástroje pro runtime governance vědí o vzájemné vazbě dvou určitých slueb a jejich SLA, mohou generovat upozornění v případě, e jedna z nich není v provozu. To můe výrazně zkrátit výpadek a omezit důsledky poruení daných SLA.
Obr. 2: Příklad dynamického vytvoření topologické mapy toků zpráv aplikací
Obr. 3: Kontrola nebezpečných slueb
Vzhledem k tomu, e nástroje pro runtime governance umoňují firmám automaticky iniciovat příslunou politiku bez toho, aby byla provázána s určitou slubou, můe být daná politika iroce aplikována na vechny sluby v síti včetně právě zjitěných nebezpečných slueb nebo slueb, které budou do infrastruktury přidány někdy později.
Například bezpečnostní pravidlo zákaznická data musí být zaifrována je bezodkladně a automaticky aplikováno na kadou zjitěnou nebezpečnou slubu, čím se chrání jak zákazník, tak samotná společnost. Kdokoli, kdo tuto slubu provozuje, pak automaticky zdědí základní rámec governance, kterému musí daná sluba odpovídat. Soulad s předpisy a vyhlákami se pak nebude zajiovat a dodatečně, ale bude realizován během celého ivotního cyklu od vývoje přes uivatelské testování a k ostrému provozu.
Ke sledování podnikových procesů slouí například software typu ghost agent (skrytý agent) pro aplikační servery, messagingové brokery apod. Tento neinvazivní software je umístěn na jednotlivých stanicích nebo zdrojích dat a odposlouchává a zachytává informace o jednotlivých událostech. Tyto informace se shromaďují a vyhodnocují ve speciálním serveru a slouí k řízení v provozním prostředí a proaktivnímu i reaktivnímu vyhodnocování jednotlivých událostí v reálném čase.
Pokud organizace můe definovat a uchopit vechny komponenty, události a systémy účastnící se daného procesu, je schopná určit, co očekává, e se v rámci procesu stane, i to, co by se stát nemělo. Okamitě pak můe zjistit, kdy proces začne fungovat patně nebo kdy dojde ke kritické události. Její schopnost spravovat a řídit, zajistit shodu s předpisy a zákony a monitorovat smlouvy o úrovni slueb se výrazně zlepí.
Sledovat a řídit SOA je moné z hlediska IT i z hlediska byznysu zároveň. IT pracovníci mohou sledovat vazby mezi jednotlivými slubami, transakční provoz i toky zpráv. Dalí podniková oddělení mají monost na provoz v SOA pohlíet ze svého podnikatelského hlediska například podle jednotlivých kategorií zákazníků.
Obr. 4: Management a registry pro SOA governance
Kadá kategorie zákazníků můe mít jiné smlouvy SLA, vyuívat jiné sluby a být jinak oetřována. Nástroje pro runtime governance umoňují zobrazit detailní pohled na jednotlivé zákazníky a na to, s jakou rychlostí či dobou odezvy pro ně přísluné sluby pracují. Pokud dojde k poruení dané SLA, zobrazí se výstraha a systém umoní přesně určit, která sluba či vazba je za toto poruení odpovědná (například kde dochází k nepřípustným prodlevám a jaká je jejich příčina).
Vizualizace a kontrola podnikových procesů umoňuje prosazování a uplatňování podnikových a IT politik, k nim patří zejména pravidla pro udrení podnikové infrastruktury v souladu se zákony a vyhlákami, údaje o oprávnění uivatelů a konzumentů slueb přistupovat do systému a vyuívat jeho sluby a procesy, bezpečnostní pravidla a smlouvy SLA.
Politiky 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 odděleně. Také pro tento úkol poskytují kvalitní nástroje pro runtime governance potřebné funkce. Vizualizace a kontrola podnikový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 runtime governance vede v konečném důsledku k tomu, e podnikový SOA systém v ostrém provozu můe dynamicky reagovat na podnikatelské příleitosti i na IT problémy, co se příznivě projeví na celkových hospodářských výsledcích celé organizace.
Autor článku je Business Consultant společnosti Progress Software Corporation, mateřské firmy Actionalu.

Mezi hlavní přísliby architektury SOA patří interoperabilita a znovupouitelnost slueb. Oba poadavky se dají plně realizovat pouze při součinnosti vech zainteresovaných sloek. Nepřekvapí proto, e právě díky SOA v minulých letech výrazně vzrostl zájem o governanci, na kterou se začal klást stále větí důraz.
V období, kdy větina společností architekturu SOA vyvíjela a navrhovala, se řídicí a kontrolní mechanismy soustředily na samotnou tvorbu slueb, procesy jejich zavádění či tvorbu WSDL a řízení SOA se zaměřovalo na předprodukční fázi.
Naproti tomu dnes, kdy v mnoha organizacích jsou sluby SOA ji zavedeny do produkčního prostředí, systémoví architekti zjiují, e nejkritičtějí problémy spojené s kontrolou a řízením se týkají právě ostrého provozu. Příli mnoho implementací SOA prostě nepracuje podle očekávání. Dochází k přeruování činnosti jednotlivých slueb, celé podnikové procesy selhávají a objevují se rizika spojená s nedostatečným zajitěním souladu s předpisy a zákony (compliance), která vedou k nákladným prodlevám. Řízení v provozním prostředí (runtime governance) se proto stává kritickou součástí celkové strategie řízení jakékoli organizace.
Dnení runtime governance
Nové nástroje pro runtime governance jsou schopné automaticky zjiovat, jaké sluby a jejich konzumenti se nacházejí v produkčních prostředích. Vyuívají k tomu software sledující přenos zpráv mezi jednotlivými slubami, přičem údaje z provozu v síti slueb jsou schopné zobrazit z technického, infrastrukturního i podnikatelského hlediska. Tyto údaje zároveň slouí k okamitému a automatickému prosazování a uplatňování souborů závazných pravidel (politik) pro řízení v provozním prostředí podle pravidel definovaných ve smlouvách SLA.Znamená to významný posun vpřed v SOA governance i výrazný pokrok v omezování rizik obvykle spojovaných s implementacemi SOA. Tam, kde architekti byli dříve schopni testovat shodu se zákony a vyhlákami jen u některých slueb, mohou nyní odpovědně prohlásit: Neexistuje ádná sluba v provozním prostředí, která není ve shodě s naí politikou.
Moderní řeení pro SOA governance by mělo umoňovat:
- automatizované zjiování poskytovatelů a konzumentů slueb,
- nabízet rozhraní pro integraci s registry/úloiti metadat,
- mapování toků zpráv a sledování vzájemných vazeb mezi slubami,
- detekci a eliminaci nebezpečných slueb,
- oddělení politik od slueb,
- vizualizaci reálných procesů pro různé typy uivatelů,
- proaktivní prosazování politik (bezpečnost, shoda s předpisy/zákony),
- změnu politik nezávisle na změnách slueb (a procesů).
Obr. 1: Z celopodnikového hlediska musí být řízení SOA uplatňováno napříč aplikacemi
Strategie runtime governance pro architektury SOA by přitom neměly být omezeny pouze na webové sluby a HTTP provozované na aplikačních serverech zaloených na J2EE a .NET, ale měly by zahrnovat i různé jiné protokoly a platformy, které převaují v reálném světě SOA, jako jsou RMI, EJB, JDBC atd.
Zjiování poskytovatelů a konzumentů
Stejně jako samotný pojem governance, také zjiování (discovery) můe být definováno mnoha různými způsoby a obvykle se uívá v různých situacích. Kdy vývojáři potřebují určitou slubu, prohledávají vechny dostupné sluby v registrech. Pokud najdou nějakou vhodnou, mohou vyuít dynamickou vazbu ke zjitění umístění instance sluby v rámci provozního prostředí. Je ale velice obtíné zjistit následující údaje:- Které sluby jsou v ostrém provozu? To, e se sluba neobjevuje v registrech, neznamená, e není pouívaná.
- Které sluby 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é sluby? I kdy je přístup ke slubě zabezpečený, nedá se zjistit, kteří konzumenti danou slubu vyuívají bez pracného prověřování kadé transakce či zprávy a procházení logovacích souborů.
Cílem automatického zjiování v provozním prostředí je kromě jiného zjistit i to, co se děje v architektuře SOA bez vědomí organizace, a poskytnout vizuální přehled dostupných slueb a dalích metadat o slubách (politiky, bezpečnostní poadavky, metriky podnikání, smlouvy SLA atd.).
Informace zjitěné během procesu governance mohou být také sdíleny v otevřených registrech nebo úloitích, které umoňují konsolidovaný přístup ke správě metadat slueb. Vývojáři i provoz mohou například vyuít slubu poskytující aktuální statistiky výkonnosti nebo informace o současné úrovni slueb. Lepí informace umoní zlepit rozhodovací proces, zvýit návratnost SOA a uspořit náklady spojené se znovupouitím slueb. Důleité jsou i sekundární výsledky, jako zlepená morálka zaměstnanců, nií náklady na podporu a vyí vyuití technologií v rámci celé organizace.
Velkým problémem můe být zjiování a správa konzumentů slueb. Organizace obvykle nemají ádnou monost jak se dozvědět, kteří konzumenti vyuívají které sluby a jaké úrovně slueb dostávají, ani zda k určité slubě nepřistupují neautorizovaní uivatelé. Navíc pokud organizace nevědí, zda sluba nebo konzument vůbec existují, těko na něj mohou aplikovat podnikové a bezpečnostní politiky.
Stejný problém je i se smlouvami SLA neexistuje způsob, jak zjistit, zda úroveň slueb, které zákazníci skutečně dostávají, odpovídá sjednané úrovni. Nástroje pro runtime governance řeí i tyto problémy, protoe umoňují IT oddělení sledovat a účtovat vyuívané sluby. Navíc poskytují vhled do iroké kály dalích problémů spojených se správou SOA:
- Pokud existuje deset konzumentů sluby, jaký vliv bude mít na ně jedenáctý?
- Jak velká kapacita určité sluby je dostupná pro nové konzumenty, kteří k ní chtějí získat přístup?
- Doba odezvy sluby je v průměru jedna vteřina. Je vech deset konzumentů této sluby spokojeno?
- Vyvinuli jsme slubu a převedli ji do ostrého provozu. Vývojový server chceme převést na nový projekt existuje někdo, kdo jej jetě vyuívá?
- Vytvořili jsme novou slubu, ale nejsme si jisti, zda je uitečná. Chceme zjistit, kdo v organizaci ji vyuívá a k čemu.
- Rád bych uíval slubu X, ale nejsem si jist, jakou má dobu odezvy, přičem právě doba odezvy je pro mně nejdůleitějí. Vím, co o slubě říká její poskytovatel, ale dostanu skutečně slibovaný výkon?
- Vyuívám slubu z jiné části organizace, kde chtějí, abych jim přispíval do rozpočtu. Vím, e jiní tuto slubu vyuívají zdarma, tak proč bych měl právě já platit?
- Jak dobře daný poskytovatel slueb dodruje smlouvy SLA, které uzavřel s jinými? Mohu věřit jeho schopnostem plánování?
Mapování toků
Kromě obvyklých údajů, které se sdílejí v registrech, jako kdo je vlastníkem sluby, kde je sluba umístěna, jakou má úroveň zabezpečení, jaký soubor pravidel je na ni aplikován apod., je nutné sdílet i informace o vzájemných vztazích a závislostech slueb. Tyto informace slouí pro analýzu základních příčin problémů, kapacitní plánování upgradů, pro verzovací sluby a plánování údrby. Mapování toků můe být pouité i pro sledování podnikových procesů a umoňuje aktivovat přísluné politiky v případě, pokud dojde k určité události, nebo naopak k určité události nedojde.Mapování toků vytváří topologickou mapu aplikací, která ukazuje, kudy zprávy fyzicky sítí proudí. Tyto vztahy se přitom zjiují automaticky, take je není potřeba konfigurovat manuálně. Pokud nástroje pro runtime governance vědí o vzájemné vazbě dvou určitých slueb a jejich SLA, mohou generovat upozornění v případě, e jedna z nich není v provozu. To můe výrazně zkrátit výpadek a omezit důsledky poruení daných SLA.
Obr. 2: Příklad dynamického vytvoření topologické mapy toků zpráv aplikací
Eliminace nebezpečné sluby
Potenciálně nebezpečná (rogue) sluba je sluba vloená do sítě slueb bez monosti jakéhokoli sledování klasickými prostředky a vdy znamená výrazné riziko pro ivotaschopnost architektury SOA:- Nebezpečná sluba můe zveřejnit citlivá data a vystavit tak společnost riziku regulačních a právních problémů.
- Nebezpečné sluby vyuívají kapacitu systému bez monosti účtování.
- Nebezpečné sluby se mohou vyhnout dodrování zákonů a předpisů tím, e obcházejí systém a proces governance.
- Nebezpečné sluby sniují motivaci dodrovat politiky governance, protoe tyto politiky na ně nelze uplatnit.
Obr. 3: Kontrola nebezpečných slueb
Vzhledem k tomu, e nástroje pro runtime governance umoňují firmám automaticky iniciovat příslunou politiku bez toho, aby byla provázána s určitou slubou, můe být daná politika iroce aplikována na vechny sluby v síti včetně právě zjitěných nebezpečných slueb nebo slueb, které budou do infrastruktury přidány někdy později.
Například bezpečnostní pravidlo zákaznická data musí být zaifrována je bezodkladně a automaticky aplikováno na kadou zjitěnou nebezpečnou slubu, čím se chrání jak zákazník, tak samotná společnost. Kdokoli, kdo tuto slubu provozuje, pak automaticky zdědí základní rámec governance, kterému musí daná sluba odpovídat. Soulad s předpisy a vyhlákami se pak nebude zajiovat a dodatečně, ale bude realizován během celého ivotního cyklu od vývoje přes uivatelské testování a k ostrému provozu.
Vizibilita podnikového procesu
Nástroje pro runtime governance umoňují organizacím zviditelnění podnikových procesů z hlediska jednotlivých procesů a celkové infrastruktury i podle specifických podnikatelských či technologických kritérií. Organizace nyní mohou zjiovat kadý podnikový proces probíhající v síti slueb, rozpoznávat infrastrukturu, která jej podporuje, a poté vytvářet procesní mapy toků zpráv. Na zjitěný proces se mohou automaticky začít aplikovat přísluná pravidla a politiky.Ke sledování podnikových procesů slouí například software typu ghost agent (skrytý agent) pro aplikační servery, messagingové brokery apod. Tento neinvazivní software je umístěn na jednotlivých stanicích nebo zdrojích dat a odposlouchává a zachytává informace o jednotlivých událostech. Tyto informace se shromaďují a vyhodnocují ve speciálním serveru a slouí k řízení v provozním prostředí a proaktivnímu i reaktivnímu vyhodnocování jednotlivých událostí v reálném čase.
Pokud organizace můe definovat a uchopit vechny komponenty, události a systémy účastnící se daného procesu, je schopná určit, co očekává, e se v rámci procesu stane, i to, co by se stát nemělo. Okamitě pak můe zjistit, kdy proces začne fungovat patně nebo kdy dojde ke kritické události. Její schopnost spravovat a řídit, zajistit shodu s předpisy a zákony a monitorovat smlouvy o úrovni slueb se výrazně zlepí.
Sledovat a řídit SOA je moné z hlediska IT i z hlediska byznysu zároveň. IT pracovníci mohou sledovat vazby mezi jednotlivými slubami, transakční provoz i toky zpráv. Dalí podniková oddělení mají monost na provoz v SOA pohlíet ze svého podnikatelského hlediska například podle jednotlivých kategorií zákazníků.
Obr. 4: Management a registry pro SOA governance
Kadá kategorie zákazníků můe mít jiné smlouvy SLA, vyuívat jiné sluby a být jinak oetřována. Nástroje pro runtime governance umoňují zobrazit detailní pohled na jednotlivé zákazníky a na to, s jakou rychlostí či dobou odezvy pro ně přísluné sluby pracují. Pokud dojde k poruení dané SLA, zobrazí se výstraha a systém umoní přesně určit, která sluba či vazba je za toto poruení odpovědná (například kde dochází k nepřípustným prodlevám a jaká je jejich příčina).
Vizualizace a kontrola podnikových procesů umoňuje prosazování a uplatňování podnikových a IT politik, k nim patří zejména pravidla pro udrení podnikové infrastruktury v souladu se zákony a vyhlákami, údaje o oprávnění uivatelů a konzumentů slueb přistupovat do systému a vyuívat jeho sluby a procesy, bezpečnostní pravidla a smlouvy SLA.
Politiky 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 odděleně. Také pro tento úkol poskytují kvalitní nástroje pro runtime governance potřebné funkce. Vizualizace a kontrola podnikový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 runtime governance vede v konečném důsledku k tomu, e podnikový SOA systém v ostrém provozu můe dynamicky reagovat na podnikatelské příleitosti i na IT problémy, co se příznivě projeví na celkových hospodářských výsledcích celé organizace.
Autor článku je Business Consultant společnosti Progress Software Corporation, mateřské firmy Actionalu.
Chcete získat časopis IT Systems s tímto a mnoha dalími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z naeho archivu.


















