Az alkalmazások leggyakrabban változó komponensei azok, amelyek valamilyen döntéshozatalt valósítanak meg (pl. felületi validáció, jogosultság kiértékelése, egy termék értékesíthetőségének meghatározása). Ezek gyakori változása lassítja és költségessé teszi az alkalmazások fejlesztését.

A T-Logic Central Permissioning Service for SOA a döntések kiemelésével és formális szabályokkal történő megvalósításával lehetővé teszi, hogy a változtatások rugalmasan, az üzleti elemzés számára átláthatóan, fejlesztői munka bevonása nélkül elvégezhetők legyenek.

Milyen tipikus, üzleti szinten is megjelenő problémákat okozhat a döntések alkalmazáskódba ágyazása?

Az eleinte egyszerűnek tűnő döntések a fejlesztés és az üzemi használat alatt is egyre bonyultabbá válnak. A felhasználók újabb és újabb igényekkel lépnek fel, amelyek megvalósítása csak lassú és költséges fejlesztéssel oldható meg.

Az alkalmazáskódokban ismétlődnek a hasonló döntéseket megvalósító elemek, vagy fordítva, az egymással összefüggő döntések egymástól elkülönülve kerülnek megvalósításra.

A fentiek következtében, a döntések egyre több helyen jelennek meg a kódokban, átláthatatlanná téve a megvalósított funkcionalitást mind a fejlesztők, mind a megbízók számára.

A megbízók túlzottan kötötté válnak a technológiákhoz és a beszállítókhoz is (vendor lock-in).

Audit esetén nehezen megállapítható, hogy a bizonyos döntések miért születtek meg.

Példák

1. Csoporttagság alapú jogosultság (XY jogosult-e végrehajtani Z feladatot?)

Kihívások	"A szokásos megoldás"			Problémák
A kezdetben egyszerű esetek egyre bonyolultabbá válnak (pl. igény merül fel a delegálások, átmeneti helyettesítések kezelésére)		Egyre több és több csoport kerül létrehozásra (100-as, 1000-es nagyságrendben...)		Karbantartása reménytelen
Fordított kérdések megválaszolása válik szükségessé (Ki jogosult végrehajtani a Z feladatot? Milyen feladatokat jogosult XY végrehajtani?)		“Egy új alkalmazásra van szükségünk, hogy ezeket kezelni tudjuk….”		Költséges és kockázatos fejlesztés kezdődik. A két alkalmazás ráadásul nem lesz kapcsolatban egymással, ami a karbantartást jelentősen megnehezíti.

2. Egy pénzügyi szolgáltatás értékesíthetőségének meghatározása

Kihívások	"A szokásos megoldás"			Problémák
Belső és külső (jogi vagy felettes szervi) szabályok kerülnek megsértésre, akár manuális hibák, akár szándékos károkozás következtében (hiányzik a kikényszerítés)		Dupla, tripla…ellenőrzés, négyszemelv alkalmazása		A manuális ügykezelést nem küszöböltük ki. Merev, nehezen változtatható folyamatok jönnek létre, amelyek auditálása is nehézkes.
Kihasználatlan üzleti lehetőségek (hiányzik az irányítás)		“Egy új alkalmazásra van szükségünk, hogy ezeket kezelni tudjuk…”		Költséges és kockázatos fejlesztés kezdődik. A két alkalmazás ráadásul nem lesz kapcsolatban egymással, ami a karbantartást jelentősen megnehezíti.
Irányítani és kikényszíteni egyidőben		Az alkalmazások szinkronizációja szükséges		Az optimális állapot nehezen érhető el

A megoldás: T-Logic Central Permissioning Service for SOA

Egy alkalmazásban ami nem weblap váltás, folyamat, és törzsadat az általában döntéshozatal, és így szabályként megvalósítható. Például ilyenek a:

felületi validációk

jogosultsági és feladatkiosztási döntések

döntési fák

igazságtáblák

értékesíthetőségi feltételek meghatározása

A TCPS legfontosabb koncepciója szerint a döntéseket ki kell emelni (externalizálni kell) az alkalmazásokból és centralizálni kell. Lényegében a TCPS-ben egy szabálymotor található, amelynek szolgáltatásait az alkalmazások a megfelelő döntési pontokon, bemenő paraméterekkel együtt meghívják. Az alkalmazások önmagukban csak a hívásokat és a visszakapott döntést feldolgozó kikényszerítő logikát kell tartalmazzák, a szabályok a szabálymotorban kerülnek kiértékelésre. A szabálymotorban a szabályok valós időben is változtathatók.

A TCPS szabályok különböző irányból kérdezhetők le: a bemenő (kontextus) paraméterek mellett teljesül-e szabály? Melyek azok a kontextus paraméterek, amelyek megakadályozzák a szabály teljesülését? A rendelkezésre álló kontextus paraméterek alapján a hiányzó paraméterek mely értékeivel lehet még a szabályt teljesíteni? A rendelkezésre álló kontextus paraméterek mellett a folyamat folytatható-e vagy meg kell állítani?

A fenti funkcionalitás egyetlen rendszerben (a TCPS-ben) történő biztosításának előnyei nyilvánvalók: rendkívüli költségcsökkentés mind a fejlesztést, mind karbantartást illetőleg.

A TCPS képes arra, hogy a döntési paraméterek hiányossága esetén kapcsolódjon más rendszerekhez, így bővítve a döntési paraméterek halmazát. Ez a fontos tulajdonság teszi lehetővé, hogy a döntés kontextusának bővülése esetén a hívó alkalmazást ne kelljen változtatni.

Fontos kiemelni, hogy a TCPS alkalmazásával az alkalmazások fejlesztése elválik a szabályrendszer megalkotásától, így ezek a sok esetben különböző csoportok által végzett tevékenységek párhuzamosíthatók.

A TCPS egyedülálló tulajdonsága, hogy a szabályokat historikusan kezeli, azaz a szabályok ütemezhetők jövőbeni, illetve visszakereshetők múltbeli állapotokra (pl. audit célból).

A TCPS kényelmes, felhasználóbarát szabályszerkesztő felülettel rendelkezik, amely segítségével az üzleti elemzők a szabad szövegesen megfogalmazott szabályokból képesek egy már a TCPS által érthető, formalizált szabályrendszert alkotni.

A TCPS az alkalmazott technológiáknak köszönhetően (JEE, LDAP, RDBMS) jól skálázható, nagy mennyiségű szabály performens lekezelésére is alkalmas, illetve magas rendelkezésre állást képes biztosítani.