Mit jelent a szabályfolyam? A szabályfolyam a szabályok és folyamatok integrációja, mely leginkább a szabályok összehangolására és végrehajtására szolgál. A Drools 4.0 azt próbálja bizonyítani, hogy nincs szükség külön folyamat- vagy szabály-orientált megközelítésre.
Az olyan vállalatok, melyek nem képesek a szabályok és folyamatok egyesített modellező rendszerré történő, igazi egységesítésére, ahogy azt például a PegaSystems is tette, nem képesek megfelelőn felkészülni a jövőbeli kihívásokra; azt, hogy a Microsoft is megértette ezt, a Workflow Foundations ajánlata mutatja, habár a szabályokkal kapcsolatos fejlesztések még igen gyerekcipőben járnak a vállalatnál. A piacon lévő vállalatokat tipikusan vagy erős folyamatok, és gyenge szabályok, vagy pedig erős szabályok, és gyenge folyamatok jellemzik – a modellezési és a végrehajtási környezetben a szabályoknak és a folyamatoknak azonban egyformán fontosnak kell lenniük.
A szabálykezelők iparágában jelenleg az állapot nélküli döntési szolgáltatásokra koncentrálnak, ahol a különálló folyamatkezelő motorok egy bizonyos idő után a különálló állapot nélküli szabálykezelő motorok támogatására szorulnak a döntéshozatal során – 30 év kutatás és fejlesztés után ez a legjobb, amit ezen a területen ajánlani tudunk: több millió eurós licencmegegyezés, amiért az egekig magasztalt táblázatkezelőket kapunk, melyeket munkafolyam motorok állapot nélküli webszolgáltatásain keresztül érünk el. A modellt ezzel nem kigúnyolni akarjuk, mivel valójában igen hasznos, de ez az integrációs szint nagyon felszínes, és biztosítanunk kell a modellek egységesítését egy sokkal mélyebb szinten. Az a modellezési környezet, melyben a szabályok és a folyamatok teljesen integráltak, más deklaratív, hozzáadott rendszerek által nyújtott előnyöket élvezi majd, mint ahogy például a Drools fejlesztői csapata is tervezi a komplex esemény-feldolgozás hozzáadását (CEP – Complex Event Processing) a motorhoz és a programozási nyelvhez – ez azt jelenti, hogy a szabályokon keresztül lehetővé válik majd az adatfolyamok és a feldolgozási mérföldkövek felügyelete.
Drools 4.0 szabályfolyam ábra
Annak az oka, hogy a szabálykezelő iparág az állapot nélküli döntési szolgáltatások modellje körül gyülekezik részben az, hogy az iparág meglévő technológiája nehezen érthető és implementálható, így nehezebb értékesíteni, a döntési szolgáltatások pedig könnyen érthetők, ezért könnyebben implementálhatók és adhatók el – a szabálykezelő motorok iparágának nagy nehézséget okoz a folyamatkezelő iparághoz képest alacsony piaci részesedésének növelése.
A jBPM fejlesztői csapata megjelentette a „Process Virtual Machine” (PVM) vízióját, de ez egy folyamatközpontú vízió. A PVM kifejezést Tom Baeyens használta először a különböző folyamatmodellek végrehajtására szolgáló generikus motorok ötletének bemutatására. A „virtuális gép” kifejezés nem feltétlenül teljesen helytálló, és már most bosszant néhány „kockafejet”, de ha továbbra is ezt a terminológiát használjuk, az almát legalább a naranccsal össze tudjuk hasonlítani az alma és zsiráf összehasonlítása helyett. Mike Brock a virtuális folyamat-motor, vagy generikus folyamat-motor kifejezések használatát javasolja, talán jó lenne eltávolodni a folyamatok és szabályok fogalmaitól valami olyasmi felé, mely az egységesített modellezési fogalmakra koncentrál.
Ez a Drools fejlesztői csapatának a víziója a PVM+-ról, ahol a szabályok, illetve folyamatok egyaránt kulcsfontossággal bírnak. A vízióban szerepelnek még a szorosan integrált modellező felhasználói felületek, a központi egységesített motor és az API-k a fordításhoz és buildeléshez, alkalmazáshoz és a futásidejű végrehajtáshoz.
Tehát, ahogy adott az alap PVM, min dolgozunk most? Még nagyon sok dolgunk van, például a fordító keretrendszer még nagyon függ a szabályoktól, így most ezt próbáljuk áttervezni, hogy mind szabályokat mind akciókat tudjon szerkeszteni. A motor változóknak jelenleg csak két hatáskörük van: globálisan és a szabályok szintjén. Biztosítanunk kell azt, hogy mind a folyamatok mind az alfolyamatok szintjén tudjunk változó-hatásköröket alkalmazni, és a szabályok végrehajtása ezen folyamatok esetén szintén azonos hatáskörrel kell történjen. Ki kell terjeszteni a szabály-időtartam fogalmát, ami egyszerűen csak egy időzítő, hogy lehetővé tegyük a cron-típusú definíciókat is. Az állapottaró magas rendelkezésreállás is lehetséges a JBoss Cache-en keresztül, emellett optimális keretrendszert kell létrehoznia perzisztencia és a helyreállíthatóság érdekében – ideális esetben ez 2008 első negyedévében készen lesz. Nincs tervbe véve, hogy a BPEL, BPM rétegekkel foglalkozunk, hanem ehelyett reméljük, hogy a jBPM fejlesztői csapata valamint az alapfejlesztők is a technológiánk felhasználóivá válnak, és a domén ezen részein dolgoznak majd.