Átfogóan tekintve egy mai IT-rendszerben az üzleti folyamat vagy funkció végrehajtásában három rendszerréteg vesz részt: kliens, köztesréteg (SOA-ban a szolgáltatás busz), valamint háttérrendszerek. Míg egy SOA-t nem használó vállalatnál ezek a rétegek ún. silókat alkotnak (vagyis egy kliens tipikusan egy köztesréteget és sok esetben csak egy háttérrendszert, egy adatbázist használ), addig SOA-környezetben fizikailag minden kliens ugyanazt a köztesréteget használja. A szolgáltatásbusz ilyen értelemben tehát kiemelten kritikus elem a SOA-infrastruktúrában, minden körülmény között biztosítani kell, hogy működőképes maradjon. Tipikus probléma szokott lenni a rosszul megtervezett SOA-t használó vállalati környezetben az, hogy egy technikailag rosszul megtervezett szolgáltatás miatt megáll vagy nagy mértékben lelassul a teljes SOA-infrastruktúra és csak a rendszerek újraindításával lehet orvosolni a kialakult helyzetet.

• A rendszerek üzemeltetői általában a következő magas szintű igényeket támasztják a Az egyes üzletileg független szolgáltatások, funkciók függetlenül működjenek egymástól. Ez azt jelenti, hogy ha egy rendszer meghibásodik, akkor az csak annak a funkciónak a működésére legyen hatással, ami üzletileg is igényli az adott háttérrendszert.

• Az egyes kliensrendszerek egymásra hatása minimális legyen, biztosítsunk lehetőséget a különböző kliens csatornák (például internet, intranet, call center, stb.) közötti különbségtételre és a rendszer erőforrások csatorna-prioritás alapú kiosztására

Annak érdekében, hogy a lehető legnagyobb rendelkezésre állást érjük el, és megfeleljünk az üzemeltetői igényeknek, a szolgáltatásbusznak biztosítania kell olyan erőforrás-menedzsment és túlterhelés-védelmi funkciókat, amelyek erőforrás-védelmet nyújtanak mind maga a szolgáltatásbusz mind a háttérrendszerek számára, illetve bizonyos esetekben a kliens rendszerek számára is. Ezeknek a funkcióknak az összességét hívjuk összefoglalóan gatekeeper funkcióknak.
A túlterhelésvédelmet és erőforrás menedzsmentet úgy kell kialakítani, hogy hívó (kliens csatornák) rendszerenként lehessen szolgáltatás szinten meghatározni bizonyos kritériumokat. A tapasztalatok alapján két fontos kritérium menedzselését mindenképpen támogatnia kell egy szolgáltatás busznak:

• Kliens csatornánként párhuzamosan futtatható szolgáltatások száma SOA-szolgáltatásonként. Ezzel biztosítható, hogy a háttérrendszerekben egy időben futtatott tranzakciók száma korlátozva legyen, vagyis ne lehessen a háttérrendszert túlterhelni. Mivel ezt az értéket kliens csatornánként kell kezelni, alkalmazásával elkerülhető a kiéheztetés, vagyis amennyiben az értékeket helyesen állítjuk be, egyik kliens sem lesz képes „elfogyasztani” az erőforrásokat a másik elöl.

• Kliens csatornánként engedélyezett sávszélesség (tranzakció/időegység).

Ennek alkalmazásával biztosítható például a DoS (Denial-of-Service) típusú támadásokkal szembeni védelem (nem mindig elég, hogy csak a párhuzamosan futtatható kérések számát korlátozzuk, hiszen folyamatos használat mellett korlátozott párhuzamos tranzakciószám mellett is túlterhelhető egy rendszer)
Kérdéses lehet a klaszter szintű túlterhelés-védelem, hiszen a rendszerek, szolgáltatásbuszok többsége klaszteres környezetben működik. Mivel a klaszter szintű erőforrás-menedzsment megoldások futásidejű költsége viszonylag magas,- hiszen meg kell oldani a klaszter tagok közötti kommunikációt a kritériumok teljesítése érdekében – általában nem érdemes a klaszter szintű teljes megoldásra törekedni. Ebben az esetben azonban tudomásul kell venni, hogy ennek hiányában a kritériumok, mérőszámok betartása csak hozzávetőleges lehet.

Timeout-kezelés
Fontos megemlíteni, hogy bár a gatekeeper funkcionalitásnak nem része a timeout-kezelés, mégis nagyban épít annak helyes megvalósítására. A timeout-kezelés elsősorban a kliens alkalmazások erőforrás-védelmére szolgál, azonban helyes megvalósítás esetén a köztesréteg erőforrásait is védi. A helyes megvalósítás azt jelenti, hogy a timeout figyelését a lehető „legmélyebb” rétegben kell elvégezni (ideális esetben a háttérrendszerben).

Gatekeeper funkciók az AquaLogic Service Bus 3.0-ban
Bár a gatekeeper funkcionalitás a fentiek alapján rendkívül fontos képessége egy gyakorlatban is jól használható szolgáltatásbusznak, a kereskedelmi forgalomban kapható termékek mégsem valósítják azt meg teljes körűen. A következőkben azt vizsgáljuk meg, hogy a piacvezető Oracle AquaLogic Service Bus 3.0 terméke hogyan egészíthető ki a gatekeeper funkcionalitással. Az AquaLogic Service Bus 3.0 rendelkezik már bizonyos gatekeeper képességekkel (http://e-docs.bea.com/alsb/docs30/operations/throttling.html), de ez nem biztosít elegendő funkcionalitást, hiszen nem valósítja meg a következőket:

• Áteresztőképesség (párhuzamosan futtatható kérések számának) kliens csatornánkénti figyelése, korlátozása

• Sávszélesség (tranzakció/időegység) menedzsmentje kliens csatornánként

A következőkben bemutatjuk, hogy az AquaLogic Service Bus 3.0-ban hogyan valósítható meg az áteresztőképesség kliens csatornánkénti menedzselése. A sávszélesség-kezelés ehhez hasonló módon biztosítható.

Működési elv
A gatekeeper alapvető működési elve a szolgáltatásbuszba befutó kérések és válaszaik figyelése, számlálása. Vagyis egy adott időpillanatban aktív, konkurens hívások számlálása, a beállított szolgáltatás – hívórendszer - limit feletti kérések visszautasítása.
A komponens az AquaLogic Service Bus-ban lévő, megvédeni kívánt szolgáltatás Message Flow-ján keresztül figyeli az adott szolgáltatás lefutását. Működése során minden egyes szolgáltatáshoz tartozó Message Flow-ba bekerül 2 db új Stage és egy Service Error Handler elem.
A biztonságos működés érdekében a rendszer nagyobb hiba esetén (háttérendszerek nem kontrollált hibái, property-fájlok elérhetetlensége, stb.) a hívásokat átengedi, hiszen ellenkező esetben a jól kiszolgált kérések is blokkolódhatnak.
A PipelinePair elem request és response ágába kerül be a két új Stage:

gateKeeperRequest stage
A request ágba a flow első lépéseként kerül be a gatekeeper eleme a gateKeeperRequest stage.
A gateKeeperRequest stage mögött egy Java Callout akció áll, ami egy külön JAR-fájlban található Java osztály egy metódusát hívja meg, a funkcionalitáshoz szükséges request paraméterekkel. Ez a Java metódus regisztrálja, számolja a beérkező kérést, feldolgozza a paramétereket, és a konfigurációban beállított adott szolgáltatás - a hívórendszer terhelhetőségi limitet figyelembe véve átengedi vagy elutasítja a kérést. A kérés elutasításakor egy SoapFaultException váltódik ki, amely tartalmazza az elutasítás okát, vagyis a túlterheltséget.

gateKeeperResponse stage
A response ágba a flow utolsó lépéseként kerül be a gatekeeper eleme a gateKeeperResponse stage. A gateKeeperResponse stage mögött egy Java Callout akció áll, ami egy külön JAR-fájlban található Java osztály egy metódusát hívja meg, a funkcionalitáshoz szükséges response paraméterekkel. Ez a metódus regisztrálja a válaszokat, feldolgozza a paramétereket, és az adott szolgáltatás - hívórendszer konkurens hívások darabszámát csökkenti eggyel.
Ha az adott kérést a háttérrendszerek időtúllépés miatt utasítják vissza, és ez az információ szabványos, előre definiált formában jelenik meg a válaszban, akkor a gatekeeper ezeket eltérően kezeli a normál válaszoktól. Az eltérés oka az, hogy az ilyen esetek nagy részében a szolgáltatás végrehajtása a háttérrendszerekben tovább folytatódik, annak ellenére, hogy a hívó megkapja a választ. Tehát ebben az esetben nem szabad a válasz elküldésekor csökkenteni a konkurens hívások számát, mert így egy újbóli hívás esetén tovább terhelődik a háttérrendszer. A GateKeeper paraméterezése során lehetőséget kell biztosítani arra, hogy beállíthassunk minden egyes háttérrendszerhez, szolgáltatáshoz, hívórendszerhez egy késleltetési időszakot, melyet a rendszer a következőképpen fog figyelembe venni: ha a szolgáltatás időtúllépés miatt tér vissza, akkor csak az adott hívórendszerhez, szolgáltatáshoz, vagy háttérrendszerhez megadott paraméterben meghatározott időszak eltelte után fogja csökkenteni a rendszer a konkurens hívások számát. Ebben az esetben a tényleges válaszkor és a konkurens hívások számának csökkentésekor is naplóbejegyzések jönnek létre.

gateKeeperErrorHandler
A Message Flow-ban kiváltódó esetleges hibák kezelésére létrehozunk egy Service Error Handler-t, melybe felveszünk egy gateKeeperErrorHandler stage elemet. A stage mögött szintén egy Java Callout akció áll. A gateKeeperErrorHandler metódus regisztrálja a hibákat, feldolgozza a paramétereket, és ezeket az eseteket eltérően kezeli a normál válaszoktól. Az eltérés oka az, hogy az ilyen helyzetekben előfordulhat, hogy a szolgáltatás végrehajtása a háttérrendszerekben tovább folytatódik, annak ellenére, hogy a hívó megkapja a hibát tartalmazó választ. Tehát ebben az esetben nem szabad a hibás válasz elküldésekor csökkenteni a konkurens hívások számát, mert így az újbóli hívás esetén tovább terhelődhet a háttérrendszer. A gatekeeperben ezekben az esetekben a „gateKeeperResponse stage” fejezetben leírt, időtúllépés miatt eltérő működés fog végrehajtódni, az ott meghatározott paraméterek alapján.