Jak implementovat SOA do existujícího systému

Pokud bychom budovali nový rozsáhlý informační systém od začátku a důsled­ně se drželi SOA paradigmat, dosáhli bychom pravděpodobně vysoce modulár
ního, otevřeného a snadno rozšiřitelného produktu s vysokou mírou dokumentovatelnosti a spravovatelnosti. Takové podmínky jsou ale v současné době v ICT spíše výjimkou.

Definování služby a realizace vazeb

Klíčovou roli hraje granualita, s níž k řešení přistoupíme. Služby můžeme zavádět do nejnižší úrovně, kde realizují atomické programové operace typu „ulož přijatou objednávku do databáze“. V tomto „aplikačním“, servisně orientovaném návrhu je kladen velký tlak na úpravu již existujících a fungujících aplikací a také prudce roste složitost implementace SOA. Z dlouhodobého hlediska nicméně dosáhneme nejlepšího výsledku. Protikladem je zapouzdření na vyšší abstraktní úrovni. Službou pak rozumíme celek typu „zpracování objednávky, její vyřízení a odeslání“. To umožní zachovat značnou část současné funkcionality, avšak za cenu snížení modularity a otevřenosti systému.

Máme-li definované služby, je nutné postoupit k realizaci jejich vazeb. V tomto kroku často narazíme na problém. Klasická SOA požaduje mezi službami zcela volnou vazbu.

Přístupy k nasazení SOA

Abychom se v praxi přenesli přes výše zmíněné nástrahy a také přes spoustu dalších, zavádějí se servisně orientované systémy do existující infrastruktury zejména dvojím přístupem.

Prvním z nich je přístup procesní. V takovém případě dochází k budování SOA metodou shora dolů. Nejprve se jasně popíšou požadované procesy uvnitř organizace a jejich současná podpora na straně existujícího informačního systému. Tím vznikne sada nově požadovaných funkcí. Jako služba se pak nejčastěji definuje zapouzdření funkcí existujícího či nově zaváděného systému do rozhraní přímo využitelného procesem (např. přijetí objednávky, vystavení faktury apod.). Paradigma volné vazby mezi systémy naplňuje nástroj pro popis, správu a řízení procesů (nejčastěji podle BPMN – Business Process Modeling Notation).

Tento přístup se uplatní zejména v silně procesně řízených organizacích, kde jsou informační toky jasně popsány a pečlivě řízeny managementem (např. bankovní sektor). Vhodnou podmínkou je rovněž už určitá sjednocenost platforem a používaných informačních standardů a doporučení (např. W3C).

Druhým přístupem je postup integrační. Ten je analogicky obdobou budování SOA zdola nahoru. Prvním krokem je rozkrytí modulů původního informačního systému, následné rozdělení do maximálního počtu nezávislých částí a definování služeb nad aktivitami, které je možné po tomto rozdělení publikovat. Vzájemné propojení a volnou vazbu pak realizuje integrační nástroj (zpravidla postavený na průmyslovém standardu BPEL), jenž také disponuje možností přizpůsobovat rozhraní modulů různými transformacemi a podporou široké palety komunikačních protoko­lů. Teprve po úspěšné SOA dekompozici lze uvažovat o realizaci procesní podpory a procesního řízení.

Integrační cesta k SOA je nejčastěji uplatňována u velmi heterogenních sy­stémů a v organizacích, kde není zavedené procesní řízení. Je využívána mnohem častěji, za což může fakt, že většina současných systémů historicky vznikala vrstvením modulů pro vyřešení jednoho konkrétního problému a časem se systém stal obtížně udržovatelným. Pro takové případy je zmapování a popis existujícího stavu výhodou integračního přístupu.

Obě cesty mají stejný cíl – poskytnout organizaci nesamoúčelnou a efektivní podporu pro její činnost a rozhodování – a díky servisně orientovanému přístupu umožnit architektonicky přibližovat také informační systémy povahově zcela rozdílných organizací. To následně zvyšuje znovupoužitelnost specificky vyvíjených aplikací a celkově snižuje výdaje nutné pro rozvoj a údržbu ICT.

Autor působí jako softwarový architekt a integrační specialista ve společnosti Aquasoft.