Řešení pro správu provozu SOA by mělo být schopné monitorovat příchozí požadavky na služby a sledovat jejich pohyb přes příslušné služby napříč celým „řetězcem závislostí“ (bez ohledu na použitý systém či protokol) až k odezvě, kterou systém poskytne konzumentovi služeb.
Vzhledem k distribuované a heterogenní povaze SOA může být tento požadavek zdrojem mnoha problémů. Patří mezi ně kromě jiného problémy se škálovatelností, modifikací a kódováním aplikací nebo s údržbou či sledováním všech souvisejících služeb a politik.
Během návrhu řešení pro správu SOA (nebo koneckonců jakékoli jiné technologie) vyvstává řada problémů ohledně toho, jak zároveň optimalizovat výkonnost, náklady, vizibilitu a škálovatelnost. Tyto cíle vypadají nekompatibilně, protože optimalizace jednoho z nich znamená kompromis u jiných.

Výkonnost a náklady

Na jedné straně potřebujeme, aby řešení pro správu a řízení provozu SOA mělo minimální výkonnostní dopad na spravované aplikace. Na druhé straně by mělo být dostatečně výkonné a akceschopné, aby zvládlo řídit všechny druhy aplikací bez ohledu na rozsah SOA prostředí. Při implementaci řešení pro správu SOA společnosti často začínají v malém a pak postupně rozsah zvětšují. Avšak s tím, jak SOA (a následně i potřeba vizibility) roste, nedostatečně robustní řešení pro správu jak serverů, tak řízených aplikací pomalu přestane fungovat.
Existuje také otázka nákladů versus přínosů. Pokud zajištění přijatelné výkonnosti nástrojů pro řízení provozu SOA znamená zvýšenou (hardwarovou nebo softwarovou) režii, kdo zaplatí za navýšenou výpočetní kapacitu a kdo z ní bude profitovat? Obvykle z ní těží IT oddělení – avšak většinou jsou to liniové úseky, kdo platí. Mělo by se po nich žádat, aby platily zvýšené náklady za režii správy, které jim nepřinášejí žádnou přímou hodnotu?
Cílem je tedy minimalizovat vliv platformy pro řízení provozu SOA na výkon CPU a zároveň minimalizovat dodatečné zpoždění aplikací vznikající vinou řídicích aktivit. Obojí je nezbytné pro to, aby se sekundární náklady na správu SOA udržely na minimu.
Za odpovídající výkonnost můžeme považovat zpoždění každé zprávy okolo padesáti mikrosekund, méně než dvouprocentní dodatečně zatížení CPU a propustnost více než tři a půl milionu zpráv za hodinu. Operátoři pak mohou sledovat každou zprávu procházející napříč SOA, přičemž server není zahlcen zprávami a spolu se sítí neubírá z výkonnosti řízení.

Vizibilita a rozpoznávání

Většina dodavatelů aplikací nabízí různě omezená řešení pro řízení provozu SOA. Mezi příklady patří dodavatelé, kteří zvládají pouze svá vlastní prostředí, nebo výrobci řešení určených jen pro jednu technologii, jako jsou buď webové služby, či portály. Účinná správa provozu SOA však musí z jednoho místa poskytnout přehled o celém prostředí SOA, který kombinuje všechny různé použité protokoly a platformy.
SOA prostředí například obvykle využívá více protokolů než jen HTTP a SOAP. Aby tedy bylo možné získat celkový přehled o jeho provozu, je třeba, aby nástroje pro správu a řízení SOA podporovaly více různých protokolů (JMS, ADO.NET, RMI, JDBC, EJB atd.).To obyčejně přesahuje možnosti řešení pocházejících od dodavatele jediné platformy.
Při automatickém rozpoznávání poskytovatelů a konzumentů služeb i závislostí mezi nimi by měly být toky zpráv mezi uzly identifikovány až na provozní úroveň a propojení jednotlivých entit zobrazeno graficky. Jen tak mohou mít operátoři jistotu, že to co očekávají, se skutečně děje.
Automatické rozpoznávání je důležitým aspektem celopodnikového nasazení SOA. V případech, kdy existují desítky tisíc vztahů mezi uzly a je možné, že tyto vztahy se změní pokaždé, když dojde ke změně nebo upgradu aplikace, je nerealistické očekávat, že podnik bude schopen tyto vztahy zmapovat manuálně a udržovat výslednou mapu vztahů aktuální.

Škálovatelnost

I když existuje mnoho druhů řešení pro správu SOA, jen málokteré z nich dokáže získat přístup k informacím předávaným mezi systémy v produkčním prostředí. A pokud to dokáže, obvykle jen za cenu výrazného a trvalého zvýšení výkonnostní režie.
Pokud nastane problém, obvykle se řešení pro správu SOA přepne do „režimu odlaďování“, aby bylo schopné sbírat podrobné informace o problému, které poslouží k jeho analýze. Přepnutí do odlaďovacího režimu však často změní parametry provozního prostředí natolik, že původní problém buď nelze řádně izolovat, nebo je třeba počkat, až se objeví podruhé (případně se už neobjeví vůbec). Naproti tomu, pokud je nástroj „stále vzhůru“, mohou operátoři zachytit všechny podrobnosti provozu SOA během porušení politik hned během jeho prvního objevení.
Ideální řešení pro správu SOA by mělo mít na jedné straně minimální vliv na výkonnost a náklady a na druhé straně by mělo neustále nabízet široký vhled do prostředí SOA. Pokud řešení pro správu nemůže splnit tyto úkoly v aktuálním ostrém provozu, nedá se počítat s tím, že by splňovalo dva první jmenované cíle.
Kvalitní nástroje pro řízení provozu SOA kombinují distribuované vyhodnocování kritérií s centralizovaným ovládáním a řízením – a umožňují tak velmi vysokou škálovatelnost. Počty spravovaných uzlů překračují tisícovku a počty sledovaných závislostí mezi službami šplhají přes padesát tisíc. Servery nebývají příčinami selhání infrastruktury, protože politiky provozu SOA jsou vyhodnocovány na spravovaných uzlech. Selhání serveru tak na tuto činnost nemá vliv.

Dědění politik službami

Automatická aplikace politik na službu podle jejích metadat v kombinaci s automatickým rozpoznáváním služeb zajišťuje, že při prvním rozpoznání služby na ni může být předem vytvořená politika automaticky aplikována podle charakteristik této služby. Nástroje pro řízení provozu SOA tak mohou zajistit, že se žádné služby do produkčního režimu nedostanou bez povšimnutí – a to dokonce i tehdy, když neexistuje explicitní mapování služeb na politiky.
Kromě toho by správa životního cyklu politik měla být nezávislá na správě životního cyklu služeb. Politika tak může mít jiného vlastníka, než mají služby, na něž je aplikována. Změna politiky nevyžaduje změnu služeb a naopak. To výrazně snižuje z dlouhodobého hlediska náklady na vlastnictví SOA politik.

Architektonické přístupy k řízení SOA

Existuje několik architektonických přístupů, které se snaží splnit výše uvedené požadavky a zároveň vyřešit doprovodné problémy. Představme si tyto architektury blíže včetně jejich kladů a záporů.

1. Distribuované zpracování
V této verzi je proces vyhodnocení politik distribuován přes síť (obr. 1). Vzniká tak řešení s velmi vysokou výkonností a značně zlepšenou škálovatelností. Jediné informace nebo zprávy zasílané zpátky na server jsou výstrahy týkající se porušení politik (například porušení SLA). Veškerá vizibilita je poskytována uzlem a server pro správu jednoduše konsoliduje zobrazování informací z různých uzlů.
Hlavní nevýhodou tohoto konceptu jsou dodatečné výpočetní nároky na úrovni aplikační platformy. Tato správní režie zvyšuje požadavky řízené aplikace na výkon CPU. To má za následek zvýšení nákladů na licence aplikačního serveru. Aby se udržela původní úroveň výkonnosti, je totiž obvykle nutné přidat do serveru další CPU.
Další nevýhodou je, že toto architektonické řešení neumožňuje nabídnout celkový přehled „zdravotního stavu“ SOA, který by byl nezávislý na jednotlivých silech nebo platformách. Jednoduché zpracování lokálních informací a zasílání výstrah zpět není dostačující.



Obrázek 1: Architektura distribuovaného zpracování

Výhody:

• Výkonnost. Vyhodnocování politik probíhá v řízeném uzlu, takže server a síť nejsou úzkým místem z hlediska propustnosti zpráv.
•  Škálovatelnost. Distribuované zpracování politik škáluje lineárně podle počtu uzlů spravovaných v síti.

Nevýhody:

• Na spravovaných uzlech dochází ke značnému vytížení CPU.
• Lokální správa uzlu neumožňuje celkový pohled na SOA.
• Zvyšují se náklady na provoz aplikací kvůli správní režii, protože k udržení výkonnosti je třeba přidat další CPU jednotky.

Nedostatky a problémy spojené s architekturou distribuovaného zpracování ukazují, že vhodnější bude centralizovanější přístup.

2. Centralizované zpracování
V této variantě je zpracování politik centralizováno, takže aplikace nemá žádné dodatečné nároky na výkon CPU vyplývající z řídicích aktivit. Řešení poskytuje celkový pohled na SOA (obr. 2). Centralizovaný server snímá zátěž spojenou se zpracováním údajů z aplikace a snižuje tak celkové nároky na CPU.
Problémy centralizované architektury však plynou z požadavků, které jsou pro řízení SOA jedinečné. Řízení SOA vyžaduje, aby monitorovací nástroje byly umístěny přímo v toku zpráv a pracovaly v aplikačních vrstvách, přičemž musí často sbírat informace z metadat nebo kontextu zpráv. Důvodem je, že řízení SOA potřebuje více informací o toku zpráv než tradiční správa aplikací.
Jinak řečeno, řízení SOA vyžaduje jak správu zpráv předávaných mezi službami, tak řízení samotných služeb. Naproti tomu tradiční správa aplikací vyžaduje pouze řízení samotných aplikací a zjišťování, co přichází dovnitř aplikace a odchází ven.
Kvůli tomu, že nástroje pro řízení SOA jsou umístěny přímo v toku zpráv a řídí zprávu za zprávou, má centralizované řízení určité nevýhody:

• Řídicí server se může stát úzkým místem a zpomalit tok zpráv, nebo ještě hůře, může se stát místem selhání.
• Pokud je každá zpracovaná zpráva zasílána ze spravovaného uzlu na centrální server, může provoz v síti výrazně a trvale vzrůst – a to až na trojnásobek.
• Zpoždění v síti jsou mnohem větší než zpoždění mezi procesy, čímž trpí celkový výkon aplikací.

Obrázek 2: Architektura centralizovaného zpracování

Výhody:

• Celkový přehled o SOA.
• Náklady na provoz aplikací jsou odděleny od nákladů na správu, protože je potřeba přidat CPU pouze v centrálním řídicím serveru. Pokud potřeby správy vzrostou, může se upgradovat řídicí server beze změny aplikační konfigurace.

Nevýhody:

• Centralizovaný server je potenciálně úzkým místem zpracování, nebo v něm může dojít i k selhání.
• Výrazný nárůst provozu v síti.
• Degradace celkové aplikační výkonnosti.
• Výrazný nárůst počtu řídicích serverů v případě zvyšování počtu uzlů v SOA.

Jak je vidět, nevýhody a problémy architektury pro centralizované zpracovávání početně zhruba odpovídají nevýhodám distribuované architektury zpracování.
Řešením by mohla být podstatně odlišná architektura, která může protichůdné požadavky splnit, a navíc bude pro aplikace transparentní. Taková architektura kombinuje oba výše uvedené přístupy.

3. Kombinovaný přístup
V tomto modelu je zpracování vyhodnocení politik distribuováno do sítě a server je „in the know“, přičemž poskytuje celkový přehled o SOA založený na informacích sdílených agentem nebo agenty (obr. 3). Dochází ke kombinaci výhod obou předchozích modelů a zároveň k odstranění jejich nevýhod.
Není překvapivé, že i tento přístup má svou „nevýhodu“: integrace se všemi rozdílnými platformami v distribuované síti vyžaduje specifickou implementaci, která je pro každý případ jedinečná. Nejde o konfekční, univerzální řešení, ale o komplexní přístup, k němuž je potřeba hluboká znalost podporovaných platforem. Ideální je, pokud příslušný nástroj poskytuje operátorům SOA jediný instalátor, z něhož jsou každá platforma a protokol vybrány během instalace.



Obrázek 3: Kombinovaná architektura

Výhody:

• Škálovatelnost. Analýza je distribuována po síti, což vede k prakticky neomezené škálovatelnosti (tj. řešení pro řízení provozu SOA se rozšiřuje lineárně s rozšiřováním celé SOA).
• Celkový pohled na SOA. Využívají se existující toky zpráv, což vede ke globálnímu zviditelnění celé infrastruktury bez centrálního úzkého místa.
• Výkonnost. Na každé řízené platformě se využívá existující způsob zpracování zpráv, což vede k nižší spotřebě výkonu CPU a vyloučení vlivu na výkonnost aplikací.

Nevýhody:

• Žádná zásadní, která by měla vliv na podnik nebo na vývojáře či operátory SOA. Je jen potřeba hluboce porozumět každé podporované platformě SOA, protože neexistuje žádné řešení, které by vyhovělo všem. Tento problém lze vyřešit, pokud příslušný nástroj disponuje jednoduchým a konzistentním instalačním balíčkem pro zákazníky.

Jak vyplývá z uvedeného, kombinovaný přístup ke správě SOA poskytuje všechny výhody jak distribuovaného, tak centralizovaného zpracování.

Autor působí již více než deset let v pražské pobočce společnosti Progress Software jako senior business consultant, kde se posledních pět let věnuje oblasti SOA, respektive servisně orientované integraci aplikací.