Aktywne reguły w systemach obiektowych (i nie tylko)

Aktywne reguły w systemach obiektowych(i nie tylko) Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa

Co to są reguły? Generalnie, są to dowolne informacje zapisane w bazie danych, których semantyka jest znana nie tylko dla ludzi, a również dla systemu. Takie informacje mogą być automatycznie interpretowane lub uwzględniane przez system. Najczęściej spotykane typy reguł: • Perspektywy (views): wyrażenia umożliwiające inny pogląd użytkownika na bazę danych • Zapamiętane procedury: procedury zapamiętane w bazie danych • Wirtualne atrybuty: atrybuty obiektów, których wartość jest wyliczana w momencie dostępu • Aktywne reguły: fragmenty kodu uruchamiane w momencie wystąpienia pewnego zdarzenia • Ograniczenia statyczne, asercje: warunki nakładane na pewne wartości lub ich kombinację • Ograniczenia dynamiczne: warunki nakładane na zmianę danych, okres ważności danych,... • Ograniczenia dostępu: reguły ustalające prawa dostępu uzytkowników do danych • ...

Reguły a reguły logiczne Pojęcie reguły ma swój prawzór w regułach występujących w dedukcyjnych bazach danych lub w programowaniu w logice (reguły Horna). Jednakże tego rodzaju reguły mają jak dotąd zerowe zastosowanie w rzeczywistych (nie urojonych) bazach danych. Podstawowa różnica z regułami logicznymi: - Reguły w bazach danych są zwykle obywatelami pierwszej kategorii, mają nazwę, granice, mogą być dynamicznie wstawiane lub usuwane ze środowiska bazy danych - Reguły w bazie danych są kodowane w dostęnym dla niej języku, np. w SQL Dość przypadkowa w gruncie rzeczy koincydencja terminu “reguła” spowodowała wyzwolenie lawiny pseudo-teorii próbujących łaczyć “deductive and active” bazy danych. Całość zamieniła się w całkowicie niestrawny najeżony formułami klajster, z którego jak dotąd dokładnie nic nie wynika (poza oczywiście kolejną publikacją na kolejną konferencję). Moją antypatią w tym zakresie cieszy się tandem S.Ceri + J.Widom. Wyjątkowe bzdury. Ostatnio ta aktywność pseudo-teoretyków w tej działce jakby przygasła. Czyżby nie mieli nic do powiedzenia? Wierzyć się nie chce...

Po co są reguły? Podniesienie “inteligencji” systemu, uwzględnienie reguł biznesu Dzięki regułom programista może być zwolniony z obowiązku kodowania explicite mnóstwa informacji wewnątrz swojego programu. Ta informacja jest zakodowana raz i może być użyta przez wielu programistów, lub tez może być użyta wielokrotnie automatycznie, bez świadomości programistów. Podniesienie bezpieczeństwa i niezawodności Reguły umożliwiają znaczne podwyższenie niezawodności działania i bezpieczeństwa danych. Programista jest zwolniony z obowiązku pamiętania o wielu elementach, które bez reguł musiałby wkomponować w swój program. Ma więc mniejsze szanse zrobienia błędu. Programista lub użytkownik jest również zabezpieczony przed popełnieniem błędu lub zaniedbania, który naruszy spójność lub bezpieczeństwo bazy danych. System jest bardziej zabezpieczony przed nieodpowiedzialnym działaniem lub sabotażem. Podniesienie poziomu abstrakcji przy programowaniu aplikacji Programista lub uzytkownik ma większą możliwość skoncentrowania się na logice aplikacji, a nie na myśleniu o tym, aby nie przeoczyć żadnego szczegółu, który może zaważyć na logice funkcjonowania, bezpieczeństwie lub spójności systemu.

Pasywna relacyjna baza danych DC DOSTAWCA DNR D1 D1 D1 D1 D1 D1 D2 D2 D3 D4 D4 D4 CNR C1 C2 C3 C4 C5 C6 C1 C2 C2 C2 C4 C5 ILOŚĆ 300 200 400 200 100 100 300 400 200 200 300 400 DNR D1 D2 D3 D4 D5 NAZW Abacki Bober Czerny Dąbek Erbel STATUS 20 10 30 20 30 MIASTO Lublin Poznań Poznań Lublin Radom CZĘŚĆ CNR C1 C2 C3 C4 C5 C6 NAZWAC Nakrętka Wkręt Podkładka Nit Nit Tulejka KOLOR Czarwony Zielony Niebieski Czerwony Niebieski Czerwony WAGA 12 17 17 14 12 19 MIASTO Lublin Poznań Rzeszów Lublin Poznań Lublin Baza danych zawiera wyłącznie wartości. Interpretacja tych wartości jest poza bazą danych

Pasywna baza danych Programy aplikacyjne ...................... ........................ Baza danych Narzędzia i udogodnienia administratora bazy danych Dostawcy Części DC Zapytania użytkowników ad hoc Generatory raportów

Aktywna baza danych Programy aplikacyjne ...................... ........................ Baza danych Narzędzia i udogodnienia administratora bazy danych Dostawcy Części DC Zapytania użytkowników ad hoc Generatory raportów Elementy aktywne, uruchamiane automatycznie bez woli programisty.

Więzy integralności, asercje CREATE TABLE table_name row_1 ...., row_2 ...., .... row_n, CONSTRAINT constraint_name constraint_definition .... SQL-92: CREATE ASSERTION assertion_name assertion_definition Asercja: maksymalna liczba czerwonych części nie powinna przekraczać 5000: Problem: kiedy sprawdzać zdarzenia i asercje? CREATE ASSERTION maks_ilosc_czerwonych CHECK ( ( SELECT SUM (DC.ILOSC) FROM DC, CZESC WHERE DC.CNR = CZESC.CNR AND CZESC.KOLOR = “czerwony”) < 5000 )

Reguły Event-Condition-Action (ECA) Aktywne reguły (active rules) Byty programistyczne (zbudowane z sekwencji instrukcji) umieszczane w bazie danych, których uruchomienie jest powodowane spontanicznie (niezależnie od normalnego przebiegu sterowania programu aplikacyjnego) przez określone zdarzenia zachodzące w bazie danych, np. aktualizację pewnej danej, upłynięcie pewnego czasu, itp. Aktywne reguły często przyjmują postać tzw. reguł ECA (Event-Condition-Action): akcja (action) jest podejmowana przez regułę wtedy, gdy zajdzie określone zdarzenie (event) oraz spełniony będzie określony warunek (condition). Aktywne reguły są często nazywane trygerami (triggers) lub regułami biznesu (business rules). Aktywne reguły są cechą wielu SZBD, w tym relacyjnych, obiektowo-relacyjnych i obiektowych. Istnieją również specjalne systemy zorientowane na tego typu reguły. Filozofia aktywnych reguł wydaje się bardzo prosta, niemniej generują one dużą liczbę problemów, których rozwiązanie nie jest trywialne. Manifest baz danych “trzeciej generacji” (Stonebraker et al) uważa aktywne reguły za pierwszorzędną cechę przyszłych systemów.

Przykładowe zastosowania aktywnych reguł Wymuszenie więzów integralnościowych Np. ktokolwiek może zmienic zarobek pracownika, ale aktywna reguła czuwa, aby nie był przekroczony budżet. W przypadku przekroczenia wyświetla komunikat i zrywa transakcję. Wymuszanie aktualizacji redundantnych danych (Np. replik, materializowanych perspektyw, dwustronnych powiązań) Po aktualizacji pewnej danej następuje automatycznie aktualizacja jej kopii lub danej pochodnej. Po aktualizacji kopii następuje aktualizacja oryginału. Monitorowanie operacji Celem sporządzania raportów i przeciwdziałaniu nadużyciom informacje o niektórych ważnych operacjach są gromadzone w odpowiednich zbiorach. Np. dostęp do informacji o zarobu powodu zapis: kto, kiedy, co z tym zrobił. Wymuszanie reguł prywatności Dostęp do pewnych danych powoduje uruchomienie akcji spradzającej, czy osoba ma do tego uprawnienia. Np. każdy może obejrzeć swoją wypłatę, ale nie może objrzeć cudzej. Deaktualizacja informacji Wiele informacji traci ważność po pewnym czasie, np. prognoza pogody, notowania giełdowe, prawa użytkowania systemu, itd. Aktywna reguła może nie tylko deaktualizaować te dane, ale również je niszczyć celem nie doprowadzenia do przypadkowej dezinformacji.

Reguły w systemie Ingres • Są one zdefiniowane przy pomocy standardowych cech SQL oraz 4GL • Są zapamiętane w bazie danych • Dla kadej zapamiętanej tablicy można wprowadzić dowolną ilość reguł • Reguły są wykonywane automatycznie na podstawie warunków zachodzą- • cych w bd, programista piszący program aplikacyjny nie musi ich • uwzględniaæ w programie. • Wykonanie reguły może uruchomić inne reguły (tzw. forward-chaining); • reguły mogą być wywołane rekurencyjnie. Rodzaje reguł w systemie Ingres: • Reguły “biznesu”, integralność wskaźników: • np. jeżeli zapas części C3 jest mniejszy od 100, wyślij zamówienie • Kontrolowanie zużycia zasobów • np. realizacja zapytania nie może trwaæ dłużej niż 5 minut; czas ten jest • oszacowany przed przystąpieniem do wykonania zapytania • Kontrola dostępu do danych • np. Kowalski należy do grupy dostępu G3, która ma dostęp tylko do tablicy DC.

Ingres: aktywne reguły Zwiększają wydajność programisty oraz podwyższają niezawodność oprogramowania. Programista przy programowaniu/modyfikowaniu aplikacji nie musi pamiętać o konieczności uwzględnienia dodatkowych akcji. Np. jeżeli stan zapasu części jest mniejszy od krytycznego, wyślij zamówienie: Stan lub zdarzenie: Warunek: Akcja: ON UPDATE poz_zamowienia IF poz_zamowienia.ilosc < :min_ilosc THEN zamow( poz_zamowienia) Akcja jest procedurą zapisaną w SQL. Jest to kawałek programu (lub wołanie procedury), który każdy programista każdej aplikacji musiałby powtórzyć, jeżeli tylko aktualizowałby zamówienie.

Ingres: zdarzenia wyzwalające aktywne reguły • akcje na wierszach tablic: • insert (wstawianie), update (aktualizacja) lub delete (usuwanie) • zmiana wartości w wyspecyfikowanej kolumnie tablicy - (update) • jakakolwiek zmiana, która spełnia warunek nałożony na jedną lub • więcej kolumn jakiejś tablicy Do czego może się to przydać: • Do wymuszenia integralności wskaźników: np. jeżeli dana pracownika • zawiera numer działu, to taki dział musi istnieć w bazie danych • Do wymuszenia generalnej integralności: np. jeżeli dodamy nowego • pracownika, to automatycznie jest dodawane 1 do danej zawierającej • liczbę pracowników • Do wymuszenia reguł biznesu: np. jak w wyżej podanym przykładzie Reguła jest nazwaną daną w bazie danych: może byæ utworzona, zmieniona i usunięta.

Reguły systemu Postgres Załóżmy, że ograniczenie mówi, że Nowak ma zarabiać tyle co Starszak: onnew PRACOWNIK.zarobek where PRACOWNIK.nazwisko = “Starszak” thendo replace P (zarobek = new.zarobek) from P in PRACOWNIK where P.nazwisko = “Nowak” Dość niefortunna składnia, rezultat radosnej twórczosci inżynierów Jeżeli aktualizowany jest zarobek (dowolny w ramach klasy) to: - zapamiętaj jego wartość pod zmienną new. - sprawdź, czy aktualizowany był zarobek pracownika o nazwisku Starszak - jeżeli nie, to nic nie rób - jeżeli tak, to pod zarobek Nowaka podstaw zmienną new. Wbrew pozorom, konsekwentne, logiczne i generalne ustawienie składni i semantyki tego rodzaju konstrukcji oraz pełne zintegrowanie ich z językiem zapytań nie jest sprawą prostą.

Reguły systemu Postgres -pozorowanie onretrieveto PRACOWNIK.zarobek where PRACOWNIK.nazwisko = “Plaka” thendoinstead retrieve (PRACOWNIK.zarobek) where PRACOWNIK.nazwisko = “Draka” Jeżeli ktoś próbuje dostać się do zarobku Plaki, to zamiast zarobku Plaki dostaje na wyjściu zarobek Draki. Tego rodzaju sztuczka może byc stosowana dla zmylenia hackerów. Metodę tę można także zastosować dla obliczania atrybutów wirtualnych: onretrieveto PRACOWNIK.wiek .... thendoinstead retrieve ( BieżącyRok - PRACOWNIK.Rok_ur) Dla języków zapytań jest to pewien problem: samo wyszukanie nie generuje zdarzenia. Jak i kiedy go generować? Znowu, głównym problemem jest ustawienie modelu od strony syntaktycznej i semantycznej tak, aby model był prosty, ogólny i konsekwentny.

Zdarzenia events Zdarzeniem jest coś, co następuje w jednym punkcie czasowym (z punktu widzenia naszej percepcji czasu) i warte jest analizowania z punktu widzenia celów projektowanego systemu informacyjnego. Samo zdarzenie nie trwa w czasie, ale fakt zaistnienia zdarzenia jest zarejestrowany i trwa aż do momentu, gdy jakiś podmiot go “skonsumuje”. Np. zdarzeniem jest naciśnięcie przez użytkownika lewego klawisza myszy, lub odlot samolotu w dniu 20 stycznia 1997 o godz. 19:00 z Warszawy do Paryża. Zdarzenia mogą być uporządkowane w czasie, ale możemy także rozpatrywać zdarzenia jak współbieżne. Zdarzenia mogą być grupowane w klasy i mogą im być przypisane atrybuty. Zdarzenia warto rozpatrywać w okreslonym kontekście, np. czym innym będzie naciśnięcie klucza Esc jeżeli użytkownik ogląda Pomoc, a czym innym będzie w głównym menu. Zwykle wystąpienie zdarzenia wywołuje pewną przyporzadkowaną mu akcję systemu, która najcześciej zmienia stan (obiektu lub sterowania).

Przykłady klas zdarzeń • samolot odlatuje( linia lotnicza, nr lotu, miasto ) • naciśnięty klawisz myszy ( klawisz, lokacja kursora ) • wprowadzono ciąg znaków ( tekst ) • podniesiono słuchawkę telefonu • wybrano cyfrę numeru telefonu (cyfra) • obroty silnika wkroczyły w niebezpieczną strefę Zdarzenia włączają błedy jako szczególny przypadek. Np. silnik się zatarł, transakcja została zerwana, czas upłynął są normalnymi wystąpieniami zdarzeń.

Generalizacja zdarzeń Zdarzenia mogą być traktowane jak obiekty, ewentualnie z atrybutami. zdarzenie czas Zdarzenia związane z akcjami użytkownika: info_wejściowe urządzenie naciśnięcie_klawisza_klawiatury kod_znaku klik_klawisza_myszy lokalizacja naciśnięcie_klawisza_myszy sterujący znakowy puszczenie_klawisza_myszy spacja alfanumeryczny interpunkcyjny

Zdarzenia jako byt systemowy Część zdarzeń w systemie należy “wszyć” w system jako zdarzenia elementarne: - nastąpił pewien moment czasowy (zadzwonił budzik) - naciśnięcie klawisza myszy - wprowadzenie nowego obiektu - początek/koniec transakcji - aktualizacja danej .... Zdarzenia złożone można komponować ze zdarzeń elementarnych (algebra zdarzeń?): - po naciśnięciu klawisza myszy w ciągu 0.2 sek nastąpiło drugie naciśnięcie - po tym jak zadzwonił budzik nastąpiło wczytanie danej - akcje firmy spadły 3 razy w ciągu tygodnia na łączną sumę ponad 100$ Programista ma mozliwość generowania zdarzeń przy pomocy specjalnych instrukcji. Jeżeli do tego ma możliwość testowania wystąpienia zdarzeń (elementarnych i złożonych), wówczas ma możliwość dowolnego ustawiania zdarzeń złożonych przy pomocy klasycznych instrukcji języka programowania. Zdarzenie ma określoną nazwę poprzez którą jest identyfikowane w systemie. Zdarzenie może mieć parametry, a raczej może być obiektem o dowolnej budowie. Zdarzenia są rejestrowane w specjalnym rejestrze zdarzeń (kontenerze).

Klasa jako miejsce przechowywania reguł Klasa jest miejscem przechowywania takich cech obiektów, które są dla nich niezmienne lub wspólne, czyli ich inwariantów. Inwarianty dotyczące jednego obiektu mogą być przechowywane w wielu klasach. Obiekt, który jest podłączony do danej klasy przechowującej jego inwarianty, jest nazywany wystąpieniem lub członkiem tej klasy. Wśród tych cech najważniejszymi są: Typ, czyli statyczna budowa obiektu (atrybuty) Metody, czyli operacje, które można wykonać na obiekcie Ale oczywiście, możliwe jest bardzo wiele innych inwariantów....

Inne inwarianty klasy Nazwa, czyli językowy identyfikator obiektu Powiązania, asocjacje obiektów danej klasy z obiektami tej lub innej klasy Wartości wspólne dla wszystkich obiektów danej klasy (stałe) Informacja o wartościach zerowych (niekiedy jest składnikiem typu) Wartości domyślne używane w momencie tworzenia nowego obiektu Zdarzenia lub wyjątki, które mogą zajść w operacjach na obiekcie Obsługa zdarzeń lub wyjątków Lista eksportowa, określająca, które atrybuty dostępne są z zewnątrz Lista importowa określająca obiekty innych klas któe są dostępne Ograniczenia, więzy integralności, którym musi podlegać każdy obiekt Atrybuty wyliczalne wraz z ich algorytmami Ikony do reprezentacji graficznej Reguły bezpieczeństwa i prywatności Informacje katalogowe, pomoce Fizyczne własności obiektów: reprezentacja metody dostępu,... Wśród tych inwariantów są również różnorodne reguły. Zasada: chociaż te inwarianty są przechowywane w ramach klasy, są one właściwe dla obiektów danej klasy (tak, jakby siedziały w ich środku).

Sformułowanie problemu zdarzenie zdarzenie zdarzenie Konsument zdarzenie zdarzenie zdarzenie Konsument Zdarzenie “wlatuje” do pewnego środowiska i trwa w nim dopóki jakiś “konsument” go nie skonsumuje. Po konsumpcji, konsument podejmuje akcję. zdarzenie zdarzenie Środowisko

Klasyfikacja zdarzeń i reakcji na zdarzenia Zdarzenie zachodzi w ramach: klasy obiektu środowiska bd Skopiować reakcję z klasy do obiektu i uruchomić Skopiować reakcję z klasy do obiektu i uruchomić klasy ??? Reakcja na zdarzenie znajduje się w ramach: obiektu ??? Uruchomić Uruchomić środowiska bd Uruchomić Uruchomić Uruchomić

Migracja zdarzeń Jeżeli zdarzenie pojawiło się w danym środowisku, to: Może być w tym środowisku przechwycone przez obsługę i zjedzone Może być w tym środowisku przechwycone przez obsługę, ale nie zjedzone. W takiej sytuacji jest przekazywane do bardziej szerokiego środowiska. W danym srodowisku może nie być obsługi danego zdarzenie; w takiej sytuacji zdarzenie ginie W danym srodowisku może nie być obsługi danego zdarzenie; w takiej sytuacji zdarzenie przelatuje dalej, do bardziej ogólnego środowiska Programista może zadecydować co ma zrobić z danym zdarzeniem: zjeść, nie zjeść, prekazać do innego. Np. zdarzeniem jest aktualizacja zarobku pracownika Kowalskiego. Jeżeli obiekt Kowalskiego lub klasa PRACOWNIK zawiera obsługę tego zdarzenia, to wchodzimy w tę obsługę; zdarzenie jest zjadane Jeżeli takiej obsługi nie ma, to zdarzenie wlatuje do środowiska bazy danych, gdzie również może znajdować się obsługa tego zdarzenia.

Aktywne reguły a transakcje Problem: jeżeli programista okreslił granice jakiejś transakcji, to jak należy traktować operacje wyzwalana przez aktywne reguły w ramach tej transakcji? Zwrócimy uwagę, że programista może nic nie wiedzieć o wyzwalanych regułach. Ponadto, może nam zależeć na tym, aby w przypadku zerwania transakcji nie cofać akcji wykonanych przez aktywne reguły (np. w celu monitorowania prób zmiany danych). Wykonanie może więc być: Natychmiastowe: w momencie wyzwolenia reguły następuje zawieszenie transakcji aż do zakończenia działania reguły. Opóźnione: reguła jest wyzwalana wtedy, jeżeli transakcja dochodzi do potwierdzenia, jako pod-transakcja. Ostateczne potwierdzenie następuje po zakończeniu działania reguły/reguł. Rozdzielone: reguła startuje nową transakcję, rozdzieloną w stosunku do poprzedniej Przyczynowo-skutkowe: reguła jest wykonywana jako nowa transakcja wyzwalana w momencie zakończenia właściwej. W przypadku zerwania tej nowej transakcji, zrywana jest także właściwa transakcja. Podstawowy problem: gdzie i jak zawrzeć informację o tym w jakim stosunku do transakcji pozostają wyzwalane reguły? Przy transakcji? Przy regule? Oddzielnie?

Trwałe wątki persistent threads Ewolucja w myśleniu o danych i obiektach: 1 generacja: dane pasywne wewnątrz danej złożonej (Kowalski, Jan, 1944, 2500) 2 generacja: dana złożona może także składać się z kodów procedur (metod) 3 generacja: dana złożona może także zawierać wątki, czyli kawałki programu, które nie tylko siedzą wewnątrz danej złożonej, ale także bez przerwy się wykonują. Trwałe wątki szczególnie trudno sobie wyobrazić, jeżeli obiekt w którym znajduje się taki wątek siedzi na dysku (jak może taki watek działać, jeżeli jest po prostu na trwale zapamiętany). Okazuje się jednak, sprawa jest implementowalna: obiekt jest ściągany do bufora w RAM jeżeli cokolwiek z nim się dzieje (np. aktualizuje). Natychmiast po ściągnięciu uruchamia się wątek od stanu, w którym on był w momencie zapamietywania na dysk. Z punktu widzenia programisty taki wątek działa cały czas. Trwałe wątki pozwalają na uzyskanie znacznie więcej mozliwości, niż dają reguły ECA. Mogą one na bieżąco monitorować stan obiektu, np. unieważniać informację po pewnym czasie (np. o notowaniach giełdowych), reagować na zmiany, przywracać stan,... Zaimplementowane w systemie TYCOON. W tej chwili trwają prace w tym zakresie w ramach Persistent Java (Pjama).

Trzy podejścia do obsługi zdarzeń 1. Wyjątki: ADA, OMG CORBA, ODMG,.... Specjalne byty programistyczne umożliwiające przekazanie sterowania do zdefiniowanego fragmentu programu po wystąpieniu błędu. Jest to “goto”, które ma zdolność przekraczania reguł zakresu. Zwija stos i nie umożliwia powrotu do stanu sprzed wystąpienia wyjątku. 2. Programowanie zdarzeniowe Program jest zorganizowany w formie bloków reakcji na pojawiające się zdarzenia. Niezwykle użyteczne dla programowania wizyjnego. 3. Aktywne możliwości w bazach danych (tryggery) Baza danych zawiera trwałe bloki, które reagują na zdarzenia. We wszystkich wymienionych przypadkach jest ta sama sytuacja: - pojawiają się zdarzenia/wyjątki - sterowanie jest przekazywane do bloku programu, który ma obsłużyć to zdarzenie Wyjątki nie zakładają asynchroniczności, jest to prawie czyste goto W pozostałych przypadkach można założyc współbieżność, chociaż jest to problem

Ingres 4GL - programowanie zdarzeniowe Inicjalizacja ramki: initialize( i = integer;) = begin i = 1; end; Czytanie tablicy dostawcy po kliknięciu myszą guzika “Czytaj”; ten kawałek progrmu może być podwiązany bezpośrednio do tego guzika: on click = begin i = 1; select wynik[i].dnr = DOSTAWCA.DNR, wynik[i].nazw = DOSTAWCA.NAZW from DOSTAWCA where MIASTO = :miasto; begin i = i+1; end; end;

Akt.reguła Akt.reguła Zdarzenia, reakcje na zdarzenia, i inne elementy środowiska Środowisko Dane (obiekty) Z Z Typ Procedura Procedura Dana Dana Z Dana Procedura Trwałe środowiska: aktywne reguły, trwałe wątki Ulotne środowiska: wyjątki, programowanie zdarzeniowe

Podsumowanie Reguły, szczególnie aktywne są bardzo ważnym dodatkiem do obiektowych baz danych Problem jest jednak w dużym stopniu ortogonalny w stosunku do obiektowości Aktywne reguły mają dość istotne asocjacje z programowaniem zdarzeniowym Pewnym problemem badawczym (moim zdaniem nierozwiązanym) jest ustawienie zarówno programowania zdarzeniowaego jak i aktywnych reguł w ramach spójnego systemu opartego o zintegrowny język zapytań i programowania Powiązanie aktywnych reguł z przetwarzaniem transakcji jest problemem Powiązanie aktywnych reguł z asynchronicznym przetwarzaniem jest problemem Migracja, rejestracja i reguły zakresu dla zdarzeń tworzą pewien problem Trwałe wątki są bardzo ciekawą koncepcją, która daje nadzieje na opanowanie problemu w sposób generalny.

Aktywne reguły w systemach obiektowych (i nie tylko)