Servisně orientovaná integrace: efektivní způsob spojování aplikací (komentář)

11. 6. 2007

Sdílet

Různé metody integrace aplikací se dají z hlediska nákladů porovnávat pouze v delším časovém úseku, do kterého se promítnou jednotlivé fáze životního cyklu – od počátečních nákladů za případné licence middlewaru, vývoj řešení, uvedení do provozu až po jeho údržbu a provozní změny. Pokud proti sobě postavíme integraci metodou špaget (těsně vázané systémy), standardní messaging (Message Oriented Middleware, EAI), samotné webové služby a servisně orientovanou integraci (SOI), můžeme zjistit, že křivka nákladů se ve všech případech poněkud liší.

Různé metody integrace aplikací se dají z hlediska nákladů porovnávat pouze v delším časovém úseku, do kterého se promítnou jednotlivé fáze životního cyklu – od počátečních nákladů za případné licence middlewaru, vývoj řešení, uvedení do provozu až po jeho údržbu a provozní změny. Pokud proti sobě postavíme integraci metodou špaget (těsně vázané systémy), standardní messaging (Message Oriented Middleware, EAI), samotné webové služby a servisně orientovanou integraci (SOI), můžeme zjistit, že křivka nákladů se ve všech případech poněkud liší.

U těsně vázaných systémů jde o téměř trvalý vzestup od relativně nízkých počátečních nákladů, kdy zákazník nekupuje žádnou softwarovou licenci, ale vynakládá nebo kupuje „pouze“ práci. Na první pohled se proto může zdát, že jde o velmi levné řešení. S postupem času však objem a složitost špaget téměř exponenciálně narůstá. Platí přitom, že minimální počet rozhraní, které by podnik musel implementovat a udržovat, se rovná n×(n-1)/2, kde n je počet integrovaných aplikací. Ne, že by nebylo možné takové řešení vyvinout a implementovat, ale nelze jej udržovat, natož měnit. Praxe již dostatečně dlouho ukazuje, že jde zcela rigidní model.

Messaging a samotné webové služby mají překvapivě společný průběh nákladů. Označením „samotné webové služby“ je zde myšleno využití pouze HTTP, SOAP a WSDL bez zastřešujícího frameworku umožňujícího skutečně podnikové nasazení. V těchto případech náklady začínají na licencí middlewaru (pokud se nejedná o čistý open source), pokračují jeho konfigurací a implementací. Připočtěme vývoj a nasazení řešení a dostáváme se ke klíčovému bodu: provoz a změny. Integrační logika je zde napevno zakompilovaná v messagingových klientech, resp. webových službách a změna typicky představuje změnu zdrojového kódu, rekompilaci, testování a nové nasazení – tento cyklus je z nákladového i časového pohledu nežádoucí.

U konceptu SOI jsou největší náklady na počátku. Obvykle začínají na (nemalé) licenci za software a jeho údržbu a pokračují vývojem, přizpůsobováním služeb a nasazením celého řešení. Z hlediska investic není SOI rozhodně nejlevnější způsob integrace, dokonce se může stát, že může být i nejdražším zvoleným způsobem (není divu, že SOA/SOI architekti dnes patří k jedněm z nejlépe placených odborníků). Tento koncept ale přesto nákladově poráží ostatní díky své architektuře, která je připravena na rychlou adaptaci – rychlé promítnutí změn, optimálně v reálném čase.

Kýženou vlastností dobře navržené SOI by totiž mělo být to, že změny se odehrají zejména v logické vrstvě, tj. v oblasti metadat – tedy popisů procesů nebo kompozic služeb. Urychlení implementace takové změny pak může být i několikařádové.
Ani v IT životě samozřejmě nefunguje vše optimálně a objevují se požadavky na změny, které zasahují do zdrojových kódů služeb. Pokud ale analýza proběhla na patřičné úrovni, měly by tyto změny být spíše v menšině.