JBoss Drools: wprowadzenie do silników regułowych – cz.1

Niemal każda większa organizacja przechowująca i przetwarzająca dane na potrzeby własnej działalności, bez względu na domenę tych danych, prędzej czy później będzie musiała stawić czoła następującemu problemowi – jak w sposób efektywny zaimplementować i utrzymywać biznesową wiedzę w systemach IT. W miarę rozbudowy bazy wiedzy i procedur biznesowych, może się okazać, że klasyczne podejście wykorzystujące repozytorium danych i zaimplementowane procesy agregujące w sobie biznesową logikę, będzie niewystarczające. Różne klasy systemów mogą wyjść naprzeciw oczekiwaniom zarówno administratorów technicznych jak i użytkowników biznesowych, oczekujących bardziej elastycznego rozwiązania umożliwiającego im zarządzanie tą wiedzą bez konieczności każdorazowej rozbudowy programistycznej wykorzystywanych narzędzi. Okazuje się, że rozwiązania zbudowane w oparciu o silnik regułowy potrafią bardzo dobrze zaadresować większość bolączek organizacji stającej przed tym problemem. Zwłaszcza, że w ostatnim okresie gotowe rozwiązania osiągnęły naprawdę dużą dojrzałość technologiczną.

Klasyfikacja silnika regułowego

Definicja i szczegółowy opis funkcjonalny silnika regułowego znajduje się w dalszej części tego artykułu, jednak warto w tym miejscu nadmienić, do jakiej klasy systemów zaliczają się narzędzia oparte o tego typu rozwiązania i jak wpasowują się w korporacyjną architekturę systemową. Historycznie prekursorami dzisiejszych silników regułowych są rozwiązania, które powstały jako jeden z elementów pracy nad sztuczną inteligencją, kiedy usilnie poszukiwano sposobów na nauczenie maszyn myślenia i wyciągania samodzielnych wniosków. Lekko zmodyfikowane podejście do tego zagadnienia znajduje zastosowanie w obszarze Business Intelligence jako uzupełnienie dla narzędzi wspierających zasilanie, transformacje i przechowywanie danych oraz ich prezentację (np. w postaci raportów). A zatem silnik regułowy można sklasyfikować jako narzędzie z obszaru Data Management, system wykorzystujący silnik regułowy może natomiast być zarówno zintegrowanym komponentem platformy BI, jak i osobnym systemem uruchomionym niejako „obok” systemów transakcyjnych (np. CRM) i z nimi zintegrowanym.

Co to jest silnik regułowy

Trzymając się jednej z najprostszych definicji, silnik regułowy to system (lub komponent systemu) informatyczny umożliwiający uruchamianie reguł biznesowych w środowisku produkcyjnym. Reguły należy w tym kontekście rozumieć jako wyrażenia odpowiadające zdaniom warunkowym: jeżeli x to y, opisujące pewną logikę i procedury biznesowe, zbudowane w oparciu o repozytorium wiedzy lub pojawiające się w systemie zdarzenia. Reguły mogą być oczywiście bardziej złożone, mogą być także od siebie nawzajem zależne albo zdefiniowane jako powiązane i prawdziwe tylko jako warunek zbiorczy, etc. Uruchamianie reguł to z kolei powtarzalny proces weryfikacji odpowiadających im warunków w danym środowisku. Należy w tym miejscu zaznaczyć, że produktem uruchomienia reguł biznesowych są na ogół nowe fakty umieszczane w repozytorium wiedzy. Silnik regułowy z zasady nie wykonuje żadnych dodatkowych operacji na podstawie tych nowych faktów (chociaż można w oparciu o nie zbudować kolejne reguły biznesowe), pozostawiając programiście decyzję co do ich interpretacji i dalszej obsługi.

Warto w tym miejscu wspomnieć, że silniki regułowe na ogół rozróżniają dwa typy reguł biznesowych (które zostały już wstępnie naszkicowane), a co za tym idzie mogą pracować jednym z dwóch trybów:

• Wnioskowanie – czyli tryb, w którym w repozytorium wiedzy przechowywane są fakty a na nich zdefiniowane są reguły biznesowe. Każda zmiana reguł skutkuje koniecznością ponownego uruchomienia mechanizmu wnioskowania, co w efekcie może przynieść inne rezultaty. Samo repozytorium faktów nie jest z kolei zasilane nowymi danymi na bieżąco, a raczej w trybie cyklicznego importu.
• Przykład: Firma telekomunikacyjna zdecydowała się wprowadzić promocję (rabat) dla klientów, którzy zakupili co najmniej jeden produkt z każdego z trzech różnych typów oferowanych przez tę firmę. W repozytorium faktów znajdują się informacje o produktach posiadanych przez klientów. Jeżeli do repozytorium wprowadzimy nową regułę biznesową, określającą, że w przypadku znalezienia na danym kliencie jednego lub więcej produktów dla każdego z trzech typów, to po uruchomieniu wnioskowania w repozytorium pojawią się nowe fakty – każdy z nich będzie określał klienta, który kwalifikuje się do tej promocji. Jeżeli warunki promocji się zmienią i zmodyfikowana zostanie reguła biznesowa w repozytorium, to wnioskowanie może zwrócić inny zestaw wyników. Podobnie stanie się po zaktualizowaniu faktów w repozytorium (np. po nocnym zasileniu informacjami o nowych produktach zakupionych przez klientów w ostatniej dobie).
• Reagowanie na zdarzenia – czyli tryb, w którym w repozytorium przechowywanych jest szereg reguł biznesowych (zazwyczaj dość stabilnych), a silnik regułowy zasilany jest na bieżąco spływającymi nowymi faktami. Ten tryb znajduje zastosowanie np. w systemach czasu rzeczywistego, kiedy trzeba na bieżąco reagować na dynamicznie uaktywniające się reguły biznesowe, ewentualnie jako komponent, który można „odpytać” o wynik uruchomienia reguł dla określonego zestawu przekazanych faktów.
• Przykład: Firma telekomunikacyjna posiada bardzo skomplikowane reguły przyznawania klientom przedłużającym umowy rabatów, w zależności od wielu kryteriów (takich jak liczba i typy posiadanych produktów, długość umowy, terminowość spłaty zadłużenia, zgody marketingowe itp.) Reguły te są relatywnie często modyfikowane i dlatego zostały wprowadzone do repozytorium jako zestaw reguł biznesowych (wzajemnie się wykluczających). Reguły te operują na faktach, które nie są przechowywane w repozytorium, natomiast są do niego wstawiane ad hoc. System wsparcia sprzedaży za każdym, kiedy musi przedstawić wyliczony rabat dla określonego klienta, łączy się z repozytorium, wstawia do niego fakty dotyczące tego klienta i uruchamia mechanizm wnioskowania. Jeżeli któraś z reguł się aktywuje i wstawie do repozytorium fakt określający wysokość rabatu, to znaczy że klient kwalifikuje się do tego rabatu i ta informacja zostanie przekazana zwrotnie do systemu sprzedaży.

Elementy silnika regułowego

Alex Berson i Larry Dubov – dwaj wybitni eksperci z dziedziny zarządzania danymi – w swojej publikacji „Mastering Data Management and Customer Integration for a Global Enterprise” definiują podstawowe komponenty, które powinien integrować silnik regułowy:

• Repozytorium danych, służące do przechowywania reguł biznesowych definiowanych przez użytkowników,
• Edytor reguł, czyli narzędzie dostarczające elastyczny i wygodny interfejs definiowania i zarządzania tymi regułami,
• Narzędzie raportowe, umożliwiające weryfikację istniejących reguł i tworzenie raportów na ich podstawie,
• Właściwy silnik uruchomieniowy, implementujący algorytmy potrafiące wnioskować i reagować na zdarzenia.

Przykładem narzędzia, które dostarcza wszystkie wspomniane komponenty jest np. JBoss Drools.

Cechy silnika regułowego

Programowanie deklaratywne

Użycie silnika regułowego pozwala zmienić sposób myślenia o podejściu do rozwiązania określonego problemu, wprowadzając prosty, deklaratywny model opisu logiki biznesowej. W odróżnieniu od klasycznego podejścia algorytmicznego stosowanego podczas programowania imperatywnego, podejście deklaratywne umożliwia sprowadzenie rozwiązanie do zbioru reguł określających „co należy zrobić”, a niekoniecznie „co należy zrobić i w jaki sposób to zrobić”. Przykładowo –użytkownika biznesowego w firmie ubezpieczeniowej może interesować informacja ilu klientów powyżej 40 roku życia zakwalifikuje się do zniżki, jeżeli odpowiednio zmienią się kryteria stażu i liczby lat bezwypadkowej jazdy. Nie musi w tym celu wiedzieć, jak połączyć dane przychodzące z różnych systemów albo w jaki sposób iteruje się po liście obiektów. Dzięki temu nierzadko bardzo skomplikowane obliczenia są dla takiego użytkownika ukryte za relatywnie prostymi regułami.

Separacja danych i logiki biznesowej

Pomimo coraz większej świadomości problemów wynikających z całkowitej separacji zespołów biznesowych i programistycznych, nadal w wielu organizacjach ciężko jest zapewnić odpowiedni poziom zrozumienia zagadnień biznesowych ze strony programistów oraz technicznych ze strony ekspertów dziedzinowych, definiujących wymagania. Zastosowanie silnika regułowego pozwala oddzielić od siebie dane i logikę biznesową opierającą się na tych danych. Dane przechowywane są w obiektach domenowych, natomiast logika zawiera się w zestawie zdefiniowanych reguł bazujących na tych obiektach. O ile z programistycznego punktu widzenia jest to niezgodne z jednym z fundamentów programowania obiektowego, zwłaszcza jeżeli przetwarzane dane pochodzą z różnych domen, o tyle dla nietechnicznych ekspertów dziedzinowych ten aspekt może być kluczowy dla zrozumienia mechanizmów definiowania biznesowej logiki w systemie i jej utrzymywania w przyszłości. Tacy użytkownicy nie muszą mieć świadomości stopnia skomplikowania algorytmów ani zawiłości modelu przechowywanych danych, wystarczy, że będą w stanie sprowadzić swoją wiedzę o domenowych obiektach oraz wymagania do poziomu reguł lub wzorców umożliwiających np. wyszukiwanie w nich określonych przypadków.

Centralizacja wiedzy

Dobrze zdefiniowane i opisane reguły mogą stanowić w organizacji centralne repozytorium wiedzy na temat biznesowej logiki. Umiejętne przygotowanie reguł i ich dekompozycja (zasada jedno wymaganie – jedna reguła), konsekwentne podejście do ich utrzymywania oraz rzetelne opisywanie mogą wręcz zastąpić, przynajmniej częściowo, dokumentację systemu, co przy rosnącej popularności podejścia agile do realizacji projektów może być bardzo dużą zaletą.

Korzyści z użycia silnika regułowego

Wykorzystanie silnika regułowego do rozwiązania pewnej klasy problemów biznesowych ma szereg zalet, o których warto w tym miejscu wspomnieć.

1. Czytelność logiki biznesowej Wymagania opisane za pomocą reguł są znacznie łatwiejsze do zrozumienia i weryfikacji przez ekspertów dziedzinowych i innych użytkowników biznesowych niż fragmenty kodu programistycznego. Tym bardziej, że bez wsparcia narzędzi takich jak silniki regułowe, programiści próbując wiernie zaimplementować skomplikowaną logikę a następnie utrzymać jej aktualność pod wpływem zmieniających się wymagań biznesowych, często padają ofiarami efektu tzw. kodu spaghetti.
2. Elastyczność rozwiązania Tworzenie nowych reguł, usuwanie nieaktualnych oraz poprawianie istniejących pod wpływem zmieniających się wymagań biznesowych jest znacznie prostsze i szybsze niż manipulowanie w kodzie programistycznym i wdrażanie zmian w systemach IT.
3. Spójność rozwiązania Translacja wymagań biznesowych na reguły opisane prostym językiem zwiększa spójność rozwiązania i umożliwia ponowne wykorzystanie wykonanej wcześniej pracy.
4. Efektywność i wydajność Silnik regułowy w trakcie przetwarzania zdefiniowanych reguł, dąży do rozwiązania wykorzystując najbardziej efektywne algorytmy, takie jak Rete i Leaps. Zazwyczaj ma on także wbudowane sprawdzone mechanizmy optymalizacyjne, dzięki którym – przynajmniej w teorii – wydajność pracy nie zależy od liczby zdefiniowanych reguł.
5. Oszczędność czasu programistów
6. Nawet w sytuacji, kiedy przygotowanie reguł spadnie na barki programisty (np. w przypadku bardzo skomplikowanej logiki), będzie on mógł skupić się na rozwiązywaniu faktycznych problemów a nie implementowaniu tasiemcowego kodu pełnego pętli i instrukcji warunkowych.
7. Oszczędność czasu użytkowników biznesowych Wiedza zorganizowana w postaci reguł skraca także czas potrzebny na wdrażanie nowych osób w daną dziedzinę.

Kiedy warto użyć silnika regułowego?

Lektura poprzednich rozdziałów może wprowadzić w mylne przekonanie, że silnik regułowy jako taki warto wdrożyć zawsze, niezależnie od domeny, skali i klasy problemu wymagającego rozwiązania. Pomimo niekwestionowanych zalet, które w pewnym sensie same określają kiedy tego rodzaju narzędzia warto jest w organizacji wdrożyć, nie jest to do końca prawda. Dlatego pytanie o silnik regułowy lepiej jest odwrócić i zastanowić się, czy są takie przypadki, kiedy jego wykorzystanie nie będzie w pełni uzasadnione.

Na pewno niski stopień skomplikowania reguł biznesowych, np. bazujących na pojedynczych obiektach domenowych i sprowadzających się do prostego schematy if-then oraz ich niewielka liczba wynikająca z niedużej liczby wymagań mogą skłonić do zastanowienia, czy warto wytaczać tak potężne działo, jak silnik regułowy. W niektórych przypadkach prosta aplikacja realizująca logikę biznesową będzie rozwiązaniem w zupełności wystarczającym i dostatecznie łatwym w utrzymaniu, żeby nie zaprzątać sobie głowy dodatkowymi elementami architektury IT. Zwłaszcza, jeżeli narzędzie wspierające biznes są już zaimplementowane i nie ma konieczności ich wymiany na inne. Podobne wątpliwości można mieć w przypadku organizacji, w których utrzymywane reguły biznesowe są stabilne i rzadko podlegają zmianom, ewentualnie realizowany projekt ma charakter jednorazowy i nie będzie modyfikowany ani utrzymywany w przyszłości – w takim przypadku wysiłek włożony w implementację i konfigurację narzędzia może nie zostać przez to narzędzie zrekompensowany na etapie użytkowania. Kryteria nie są tutaj jasno zdefiniowane, dlatego każdy przypadek należy rozważyć indywidualnie, warto jednak mieć świadomość na co zwrócić uwagę podejmując decyzję o wdrożeniu lub nie narzędzi opartych na silnikach regułowych.

Jeżeli w danej organizacji kluczowym kryterium jest wydajność pracy narzędzia realizującego biznesową logikę, może się okazać, że dedykowane rozwiązanie innej klasy będzie lepiej dostosowane do wymagań pozafunkcjonalnych. Należy pamiętać, że żaden algorytm nie sprawdzi się równie dobrze dla wszystkich klas problemów. W ujęciu statystycznym algorytmy Rete i Leaps wypadają bardzo dobrze, ale może się okazać, że w specyficznych przypadkach bardziej wydajne będzie zaimplementowanie rozwiązania opartego na innych algorytmach.