A szolgáltatás-orientált architektúra koncepciója nem újkeletű informatikai stratégia, az Egyesült Államokban régóta ennek mentén fejlesztenek, és egyre inkább terjed itthon is. Mint Németh László, az Alerant Rt. technológiai igazgatója lapunknak elmondta, Magyarországon még nagyon sok monolit-képződmény van vállalati szinten. A SOA lényege, hogy ezeket a mega-alkalmazásnak nevezhető rendszereket kisebb, komponensekre osztott részegységenként ajánlják a fejlesztő vállalatok, és ezekből az egységekből az ügyfél összeállíthatja a neki megfelelő szolgáltatás-halmazt, azaz informatikai rendszert. A koncepció az, hogy meg kell keresni azokat a funkciókat, amelyekre szükség van, és azokat kell implementálni először, tehát azokat a szolgáltatásokat, amelyekre a vállalaton belül bárkinek szüksége lehet. Fontos szempont: nem arra kell koncentrálni, hogy az adott pillanatban mit kell megoldani, hanem arra, hogy olyan szolgáltatás kialakítani, amely esetleg nagyon sok projektnek ugyanolyan jó lesz.
A hagyományos alkalmazás-fejlesztés olyan monolitikus alkalmazásokat eredményezett, amelyeken belül egy bizonyos funkció több helyen is megvolt. Ez egyrészt pazarlás is volt, másrészt ha bármilyen változásra volt szükség, akkor mindegyikben végig kellett vezetni, ugyanolyan módon. Egy-egy műveletet két különböző rendszerben végeztek el, például az A iktatókönyvben iktattak a vállalat egy részében, egy másikban pedig a B iktatókönyvben. Ez két különböző szoftvert jelentett, és ha bármilyen belső folyamat vagy szabályozás megváltozott, akor ezt két helyen kellett módosítani. A SOA-megközelítés ezzel szemben az, hogy legyen egy iktatás-szolgáltatás a vállalaton belül. Ehhez természetesen arra is szükség van, hogy a vállalat vezetésének határozottan kell végigvinnie az implementálást. Azaz mindenkinek, akinek egy adott szolgáltatási szükséglete van, annak egyrészt föl kell derítenie, hogy van-e már olyan, és ha megtalálta és létezik olyan szolgáltatás, akkor kötelező azt használni. Ez nem mindig egyszerű, mert előfordulhat, hogy alkalmazásonként bizonyos dolgokat egy kicsit másképpen szeretnénk megcsinálni, de ha SOA-alapon történik a fejlesztés, akkor azonnal kiderül, hogy valamelyik folyamat nem megfelelően kerül kialakításra, hiszen a vállalaton belül egy bizonyos műveletet csak egyféleképpen lehet csinálni.
A szolgáltatás-orientált megközelítést egyébként már régen felismerték, és nagyon sok vállalat elkezdett ebbe az irányba „mozogni”. Például: felmerült egy vállalatnál, hogy szükség van egy iktató-szolgáltatásra. Egy bank vagy egy mobilvállalat esetében sok más – több folyamat által használt - szolgáltatás jelenik meg. Ekkor a fejlesztők akadályba ütköznek, mivel elkezdik fejleszteni a szolgáltatásokat, de nincs olyan egységes platform, ami integrálni tudná ezeket a szolgáltatásokat. A vállalatok nagy része jelenleg ott tart, hogy van több szolgáltatásuk, de nehezen, vagy egyáltalán nem tudnak velük mit kezdeni, mert sok van belőlük és nem látják át ezeket. Ebben segít a BEA Aqualogic és az Aqualogic Service Bus: rendet tesz abban a „kazalban”, amit az idők folyamán előállítottak a fejlesztők. Akkor is, ha alaptechnológiai szinten, koncepcionálisan jó volt az elképzelés, csak nem volt hozzá olyan eszközkészlet, ami ezt menedzselni tudta volna. Az Aqualogic Service Bus a szolgáltatás-orientált (SOA-alapú) elemek integrációját végzi, és emellett monitorozó képessége is van – azt az üzenetfolyamot, amely a szolgáltatások között folyik, monitorozhatóvá, felügyelhetővé is teszi nemcsak az IT, hanem az üzlet számára is (ez a business activity monitor). Ehhez járul hozzá a jogosultság-kezelés és a változás-kezelés, továbbá egy olyan funkció, amely egy szolgáltatás megváltoztatása esetén jelentést keszít arról, hogy a változás hol okozhat problémát.
Fontos megemlíteni, hogy nem egyszerűen egy integrációs eszközről van szó, hanem egy menedzsment-eszközről, amely a szolgáltatások változtatásainak menedzselését, megfigyelhetőségét teszi lehetővé – hangsúlyozta Németh László.