pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Rozdział 2
w
Aktywny system zarządzania bazą danych jako
kontroler homogenicznego środowiska aplikacji
w
1 Wstęp
da
.b
w
Streszczenie. Aktywny system zarządzania bazą danych jest w stanie
reagować w sposób automatyczny na zdarzenia zachodzące w bazie danych
oraz poza nią. W pierwszej części rozdziału przedstawiono najważniejsze
pojęcia z dziedziny aktywnych systemów zarządzania bazami danych oraz
klasyfikację tych systemów. Możliwości wykorzystania wybranej klasy
aktywnych systemów zarządzania bazą danych (kontrola homogenicznego
środowiska aplikacji) przedstawiono na przykładzie systemu przeznaczonego
do zarządzania kontami klientów telefonii komórkowej. Aby umożliwić
kontrolę środowiska bazy danych zdefiniowano odpowiednią bazę reguł
ECA. Opis budowy i zachowania zaawansowanych reguł, reagujących na
złożone sekwencje zdarzeń wzbogacono odpowiednimi diagramami UML.
pl
s.
Pojawienie się skomplikowanych z natury aplikacji, mających jednocześnie duże
zapotrzebowania na rozmiar bazy danych doprowadziło do rozszerzenia funkcjonalności
systemów zarządzania bazami danych. Jedną z możliwości wsparcia aplikacji przez system
zarządzania bazą danych jest wyposażenie go w możliwości monitorowania
i samodzielnego reagowania na szeroki wachlarz sytuacji, jakie mogą zajść w
rzeczywistych aplikacjach. Takie podejście pozwala przenieść część logiki biznesowej z
warstwy aplikacji do warstwy danych. Zalety są następujące:
− możliwość współdzielenia funkcjonalności przez wiele aplikacji, co zmniejsza
poziom zduplikowania kodu;
− wykorzystanie wzorca reguły ECA prowadzi do zmniejszenia zabiegów
implementacyjnych potrzebnych do dostarczenia wymaganych funkcjonalności;
− możliwość modyfikowania logiki biznesowej umieszczonej w warstwie danych
w sposób niezauważalny dla użytkowników i aplikacji.
Samodzielna reakcja systemu bazodanowego oznacza, że jest on w stanie podjąć pewną
akcję niezależnie od działań użytkownika lub aplikacji. Specyfikacja sytuacji, na które
system będzie reagował może odbywać się za pomocą reguł ECA (ang. event-conditionaction). Semantyka reguły ECA jest następująca: „jeśli zajdzie zdarzenie E i jeśli jest
spełniony warunek C wówczas, podejmowana jest akcja A”. Modelowanie reguł odbywa
Robert Bar, Zygmunt Mazur: Politechnika Wrocławska,
Wydział Informatyki i Zarządzania, Instytut Informatyki Stosowanej,
ul. Wybrzeże Wyspiańskiego 27, 50-370 Wrocław, Polska
email: [email protected], [email protected]
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
R. Bar, Z. Mazur
w
się za pomocą języka definiowania reguł. Składa się on z konstrukcji pozwalających na
definiowanie zdarzeń, warunków, akcji. Wszystkie zdefiniowane reguły składowane są w
tzw. bazie reguł i są traktowane (podobnie jak schemat bazy danych) jako metadane.
Aktywny system zarządzania bazą danych (ang. ADBMS – Active Database Management
System) rozszerza pasywny system zarządzania bazą danych o możliwości specyfikowania
i wykrywania zdarzeń oraz dostarcza mechanizmy wykonywania akcji, które określają
reakcję systemu na pojawiające się zdarzenia. W idealnym rozwiązaniu ADBMS to system,
który wykrywa wszystkie rodzaje zdarzeń. Gdy programiści aplikacji lub sami
użytkownicy są odpowiedzialni za sygnalizację wystąpień wszystkich zdarzeń wówczas
mamy do czynienia jedynie z wariantem pasywnego systemu zarządzania bazą danych.
ADBMS jest odpowiedzialny za wyliczenie wartości logicznej warunku C reguły ECA w
następstwie zdarzenia E oraz za wykonanie akcji A, jeśli warunek ten zostanie spełniony.
Warunek C jest najczęściej zapytaniem do bazy danych, którego niepusty rezultat określa
spełnienie tego warunku. Akcja A jest dowolnym wykonywalnym fragmentem kodu.
Na podstawie roli, jaką będzie pełnił ADBMS w środowisku aplikacji można dokonać
klasyfikacji aktywnych systemów zarządzania bazami danych. Drugi podrozdział
niniejszego rozdziału poświęcono w całości na przedstawienie owej klasyfikacji. Aby
przybliżyć zalety wykorzystania ADBMS w podrozdziale trzecim pokazano, w jaki sposób
można wykorzystać aktywny system zarządzania do kontrolowania środowiska aplikacji,
które współdzielą te same bazy danych. W opracowaniu przykładu wykorzystano
doświadczenia zdobyte w czasie budowy aktywnego obiektowo-zorientowanego systemu
zarządzania bazą danych. ActiveJDO jest propozycją rozszerzenia standardu JDO 1.0
o możliwości definiowania i przetwarzania reguł ECA [1][2]. Podrozdział czwarty zawiera
podsumowanie i wskazuje obszary dalszych badań nad aktywnymi systemami zarządzania
bazami danych.
da
.b
w
w
2 Klasyfikacja aktywnych systemów zarządzania bazami danych
pl
s.
Podstawą do kategoryzowania aktywnych systemów zarządzania bazami danych jest
przyjęcie założenia, że klasa do której należeć będzie ADBMS, zależy od strategii jaką on
przyjmuje realizując swoje funkcjonalności. W pracy [3] wskazano dwa podstawowe
aspekty, których sposób realizacji może wskazywać na klasę ADBMS:
− rola ADBMS w systemie aplikacji: nadzór (ang. supervision) lub kontrola (ang.
control);
− stopień integracji ADBMS z środowiskiem aplikacji: system homogeniczny lub
heterogeniczny.
Aktywny system w roli nadzorcy weryfikuje żądania operacji na bazie
danych i ewentualnie wykonuje proste akcje (np. powiadamianie użytkownika, wycofanie
transakcji, rozpropagowanie uaktualnień). Natomiast ADBMS kontrolujący środowisko
aplikacji jest w stanie dodatkowo uruchamiać zewnętrzne aplikacje. W tej roli ADBMS
może kontrolować nie tylko stan bazy danych, ale również zachowanie całego środowiska
aplikacji.
Środowisko aplikacji będzie można nazwać homogenicznym, jeśli wszystkie aplikacje
współdzielą schematy bazy danych oraz posiadają wspólne bazy danych. W przeciwnym
razie mamy do czynienia z heterogenicznym środowiskiem aplikacji.
Kombinacja możliwych ról, jakie może pełnić ADBMS oraz stopni integracji ADBMS z
środowiskiem aplikacji prowadzi do powstania trzech klas aktywnych systemów, które
można opisać następująco:
28
Aktywny system zarządzania bazą danych jako kontroler homogenicznego środowiska aplikacji
w
− Nadzorca homogenicznego środowiska aplikacji to najprostsza w budowie klasa
aktywnych systemów. Zadaniem takich systemów jest weryfikacja żądań aplikacji
wobec stanu bazy danych. Możliwości tej klasy systemów ograniczają się do
powiadamiania użytkownika i cofania transakcji. Taki rodzaj ADBMS jest użyteczny
podczas implementacji zwykłych zadań dla DBMS, takich jak: sprawdzanie
integralności danych, autoryzacji użytkowników, uaktualnień widoków.
− ADBMS jako kontroler homogenicznego środowiska aplikacji ma możliwość
kontrolowania nie tylko bazy danych, ale również środowiska aplikacji. Aktywny
system oprócz posiadania możliwości nadzorcy jest w stanie wykrywać stany lub
sekwencje stanów środowiska aplikacji i reagować na nie, włączając w to
uruchamianie programów. Kontrolowanie złożonych sekwencji zdarzeń wymusza
istnienie złożonych typów zdarzeń.
− Kontroler heterogenicznego środowiska aplikacji jest w stanie integrować
autonomiczne systemy. Do możliwości klasy opisanej powyżej należy dodać
wykrywanie zdarzeń zachodzących w innych systemach, które mogą bazować na
innych DBMS. Uruchamianie akcji nie musi odbywać się pod kontrolą lokalnego
menadżera transakcji. Kontrola heterogenicznego środowiska wymaga również
przeniesienia części warstwy pośredniczącej (ang. middleware) do ADBMS.
Mimo jeszcze jednej dostępnej kombinacji czwarta możliwa klasa ADBMS czyli nadzorca
heterogenicznego środowiska jest uznawana za pozbawioną własnego znaczenia [3].
da
.b
w
w
3 Przykład kontrolera homogenicznego środowiska aplikacji
pl
s.
W niniejszym podrozdziale zostaną przybliżone wymagania stawiane przed aktywnymi
systemami zarządzania bazami danych pełniącymi rolę kontrolera aplikacji, które
współdzielą te same bazy danych. Jak już wspomniano w poprzednim podrozdziale, od tej
klasy ADBMS wymaga się dostarczenia szerszego zakresu funkcjonalności od tego jaki
jest potrzebny do pełnienia roli nadzorcy. W najprostszej klasie ADBMS wystarcza obsługa
zdarzeń prostych, pochodzących z systemu zarządzania bazą danych (np. zdarzenia
transakcji), zdarzeń mających miejsce w samej bazie danych (np. zdarzenia zmiany
wartości atrybutów obiektu) oraz zdarzeń czasowych (np. wskazanie przez zegar danej
godziny). Projektant bazy reguł może jeszcze tylko określić zależność pomiędzy transakcją,
w której pojawiło się zdarzenie (tzw. transakcja wyzwalająca), a transakcją rozpoczętą na
rzecz wykonania akcji (transakcja wyzwolona). Wyróżnia się następujące tryby sprzężenia
owych transakcji:
− w trybie bezpośrednim wykonanie akcji ma miejsce natychmiast po zajściu zdarzenia
i odbywa się w ramach transakcji zagnieżdżonej w transakcji wyzwalającej;
− w trybie opóźnionym transakcja wyzwolona jest również transakcją zagnieżdżoną,
jednak jej wykonanie jest odroczone do zakończenia transakcji wyzwalającej;
− w trybie rozłącznym wykonanie akcji rozpoczyna się w osobnej transakcji.
W pracy [1] pokazano również, w jaki sposób sprzężenia transakcji wyzwolonej
i wyzwalającej można ustalać osobno dla wykonania akcji i warunku. Na tym kończą się
możliwości modelowania reakcji w najprostszej klasie ADBMS. Cechą charakterystyczną
dla pozostałych klas ADBMS jest konieczność wspierania przez nie złożonych typów
zdarzeń, które należy rozumieć jako zdarzenia skomponowane z innych zdarzeń (prostych
lub złożonych). Dostarczenie zdarzeń złożonych daje projektantowi bazy reguł możliwość
implementowania reguł ECA, które będą realizować operacje w odpowiedzi na specjalnie
zdefiniowane sekwencje zdarzeń. Podstawowe typy zdarzeń złożonych tworzy się za
29
R. Bar, Z. Mazur
w
pomocą tzw. konstruktorów zdarzeń. Podczas prac nad prototypem aktywnej warstwy [2]
wyszczególniono następujące konstruktory zdarzeń złożonych:
− konstruktor dysjunkcji DYSJ(E1, E2), który określa zdarzenie zajścia jednego ze
zdarzeń składowych;
− konstruktor sekwencji SEQ(E1, E2) opisuje zajście zdarzenia E2 poprzedzonego
zajściem zdarzenia E1;
− konstruktor koniunkcji CONJ(E1, E2) określa konieczność wystąpienia obu zdarzeń
składowych aby zasygnalizowane zostało jedno zdarzenie złożone;
− konstruktor tzw. zdarzenia negatywnego NEG(E, TI) opisuje sygnalizację zdarzenia
złożonego pod warunkiem, że przez określony okres czas TI nie zostanie zgłoszone
ani jedno wystąpienie zdarzenia E;
− konstruktor pierwszego wystąpienia FO(E, TI) ma następujące znaczenie: jeśli w
czasie trwania interwału czasowego TI pojawi się po raz pierwszy zdarzenie E,
wówczas zostanie zasygnalizowane zdarzenie złożone. Kolejne wystąpienia
zdarzenia E będą ignorowane, aż do zakończenia bieżącego przedziału czasowego TI.
− konstruktor historii zdarzeń H(E, N, TI) definiuje zdarzenie złożone, które do
wystąpienia potrzebuje N-krotnej sygnalizacji zdarzenia E w podanym okresie czasu
TI.
Aktywny system zarządzania bazą danych akceptujący tak określone zdarzenia złożone jest
już w stanie kontrolować zachowanie środowiska aplikacji, co zresztą zostanie pokazane
w bieżącym rozdziale. Zanim jednak omówiony zostanie przykład, warto zwrócić jeszcze
uwagę na możliwości dalszego uściślania, kiedy może nastąpić reakcja na dane zdarzenie
złożone. Otóż z każdym wystąpieniem zdarzenia związana jest informacja o źródle
zdarzenia oraz transakcji wyzwalającej. W zaawansowanych ADBMS projektant bazy
reguł może wymagać, aby do sformułowania zdarzenia złożonego były brane wyłącznie
wystąpienia zdarzeń pochodzących z tej samej transakcji i/lub źródła.
Do celów poglądowych zaprojektowano uproszczony system zarządzający kontami
klientów sieci komórkowej. Do realizacji funkcjonalności warstwy danych wybrano
ADBMS, który może pełnić rolę kontrolera w homogenicznym środowisku aplikacji.
Specyfika modelowanej dziedziny wymaga dostarczenia elastycznego mechanizmu zmiany
reguł biznesowych, np. naliczających koszty rozmowy. Dzięki regułom ECA,
przechowywanym w bazie reguł i zarządzanym tak samo jak inne dane taki mechanizm
z powodzeniem posiada wspomniany ADBMS. Wystarczy zmodyfikować zbiór reguł, aby
reakcja ADBMS odpowiadała nowym wymaganiom. Na rysunku 1 przedstawiono
architekturę projektowanego systemu. Komponent CallManager odpowiedzialny jest za
obsługę rozmów telefonicznych. Komponent ten w określonych jednostkach czasu zleca
naliczanie kosztów rozmowy komponentowi AccountManager, służącemu do obsługi kont
klientów telefonii. Komponent AccountManager odpowiada również za realizację płatności
klientów. Dane o aktualnym stanie konta klienta, o historii rozmów, historii płatności
przechowywane są w aktywnym systemie zarządzania bazą danych ActiveJDO. Oprócz
realizacji funkcjonalności typowej dla bazy danych ActiveJDO jest w stanie wywoływać
operacje oferowane w dostępnych interfejsach pozostałych aplikacji. Ostatnim
wyróżnionym komponentem jest SMSSender udostępniający usługę wysyłania krótkich
wiadomości tekstowych. Znając architekturę systemu można zaprezentować możliwości
użycia ADBMS do wyrażania ważnych (z punktu widzenia prowadzonej działalności) reguł
biznesowych. W tym celu zdefiniowano kilka przykładowych reguł, których opis
zamieszczono poniżej:
− reguła 1: „Jeśli klient rozmawiał łącznie 100 minut w styczniu 2006 r. w godzinach
18-22 i nie skorzystał z promocji w grudniu 2005 r., a jego rachunek telefoniczny za
da
.b
w
w
pl
s.
30
ostatnie 3 miesiące wynosi łącznie więcej niż 1000 zł, wówczas podjęta zostanie
akcja wysłania SMS do klienta z ofertą tanich rozmów”;
− reguła 2: „Jeśli klient, który rozpoczął rozmowę i nie uregulował rachunku za
poprzedni miesiąc i stan zadłużenia jest większy niż 700 zł wówczas podjęta zostanie
akcja przerwania rozmowy”;
− reguła 3: „Jeśli klient rozpoczął 5 minutę rozmowy koszt minuty połączenia spada do
50%”.
w
id Mobile System
w
w
Komponent SMSSender
oferuje usługę wysyłania
krótkich wiadomości
tekstowych. Usługa ta jest
oferowana poprzez
interfejs SendMessage
InternetSMS to przykładowy komponent, którego
zadaniem jest realizacja żądań wysłania
wiadomości SMS. Żądania te są zgłaszane na
stronie internetowej przez klientów i po
przetworzeniu są przekazywane do komponentu
SMSSender, oferującego wysłanie
przygotowanej wiadomości.
InternetSMS
Activ eJDO
da
.b
SMSSender
Send Message
Call Handling
ActiveJDO to komponent
reprezentujący aktywny system
zarządzania bazami danych.
Baza reguł tego ADBMS
zawiera reguły biznesowe, które
w odpowiedzi na pewne
zdarzenia pozwalają na
kontrolowanie całego
środowiska aplikacji. Jako że
akcje reguł są wykonywalnymi
fragmentami kodu, mogą
korzystać z każdego interfejsu
oferowanego przez pozostałe
komponenty (SendMessage,
CallHandling, Payment). Dzięki
regułom ECA możliwe jest
wysyłanie sms-ów, przerywanie
rozmowy, modyfikowanie
parametrów naliczania kosztów
rozmowy itp. niezależnie od
przebiegu sterowania
komponentów.
Payment
Account Details
Count Up
CallManager
Komponent odpowiedzialny za zarządzanie kontami
klientów. Aby naliczać opłaty za wykonywane rozmowy
komponent AccountManager oferuje interfejs CountUp,
poprzez który będzie informowany o każdej upływającej
jednostce czasu każdego połączenia. W tym wypadku za
informowanie o upływających jednostkach
odpowiedzialny jest komponent CallManager. Kiedy
AccountManager dostaje dane o upłynięciu jednostki
czasu, wtedy dokonuje modyfikacji danych konta
rozmawiającego klienta. Dane kont przechowywane są w
aktywnej bazie danych i dostępne poprzez interfejs
AccountDetails.
pl
s.
Komponent CallManager przechowuje informacje
na temat aktywnych połączeń.
Komponent ten oferuje interfejs CallHandling,
poprzez który można:
- sygnalizować rozpoczęcie rozmowy
- sygnalizować zakończenie rozmowy.
Po rozpoczęciu rozmowy CallManager jest
odpowiedzialny za przekazywanie informacji o
upływających jednostkach każdego aktywnego
połączenia. Informacje te są przekazywane
poprzez interfejs CountUp do komponentu
AccountManager, który jest odpowiedzialny za
modyfikowanie stanu konta klientów.
AccountManager
Rys. 1. Komponenty przykładowego systemu zarządzającego kontami klientów telefonii
komórkowej wykorzystującego ADBMS do kontroli środowiska aplikacji
Cechą charakterystyczną tych reguł jest to, że każda z nich wpływa na działanie innej
części systemu. Oczywiście takich reguł może być w bazie reguł znacznie więcej, nic
również nie stoi na przeszkodzie, aby np. definiować nowe reguły w czasie działania
systemu.
31
R. Bar, Z. Mazur
w
Mechanizmem, który przychodzi z pomocą projektantowi bazy reguł przy określaniu
aktualności nadchodzących zdarzeń są interwały czasowe. Instancje dowolnego zdarzenia
mogą być weryfikowane pod względem czasu wystąpienia. Jeśli wystąpienie zdarzenia
będzie miało miejsce poza określonym interwałem czasowym, wówczas nie zostanie ono
nawet zasygnalizowane. Interwały czasowe podobnie jak zdarzenia dzielą się na proste i
złożone. Istnieją dwa rodzaje interwałów prostych:
− interwały pojedyncze określane są na podstawie daty początkowej i końcowej;
− interwały cykliczne określają powtarzające się przedziały czasu, których długość
zależy od przyjętej podstawy czasu (może to być rok, miesiąc, dzień itd. );
Przykładowo w trybie dziennym oczekujemy na zdarzenia każdego dnia pomiędzy
określonymi godzinami.
Zwiększenia precyzji w modelowaniu interwałów czasowych można dokonać
wykorzystując interwały złożone, które są skomponowane z innych interwałów czasowych:
− suma interwałów składowych określa wszystkie dostępne przedziały czasu
(niekoniecznie zazębiające się);
− część wspólna interwałów czasowych określa wyłącznie nakładające się na siebie
części przedziałów składowych.
Mając tak rozbudowany zestaw konstrukcji do definiowania interwałów czasowych, można
modelować bardzo wyszukane przedziały czasowe. Przykładowo możemy określić, że
spodziewamy się sygnalizowania zdarzeń między godziną 08:00 a 09:00 w poniedziałki,
środy i niedziele w latach 2005-2010 w miesiącach kwiecień oraz maj (dekompozycja na
interwały składowe wymaga zdefiniowania ośmiu interwałów, w tym dwóch złożonych).
Na rysunku 2. za pomocą diagramu obiektów UML przedstawiono dekompozycję
pierwszej reguły, kontrolującej aplikację SMSSender.
da
.b
w
w
cd Bonus Rule
Reguła jest wzywalana kiedy użytkownik wydzownił 100 minut w styczniu 2005
pomiedzy 18:00 a 22:00 godziną i dodatkowo nie wykorzystał promocji w
grudniu 2005. Akcja jest wykonywana wyłącznie gdy suma rachunków klienta w
oststnich 3 miesiącach przekroczyła 1000zł. Podczas wykonywania akcji
wysyłana jest krótka wiadomość tekstowa z ofertą promocyjną.
sygnalizacja nastąpi gdy zajdzie sekwencja
SEQ(initalEvent, terminationEvent)
ThreeMonths :
Condition
+terminationEvent
+initialEvent
DecemberPromoUnused :
Negativ eConstructor
+E
EnablePromo :
AbstractEv ent
SendSms :
Action
BonusRule :Rule
BonusEv ent :
SequenceConstructor
HundredMinutes :
HistoryConstructor
::HistoryConstructor
- N: int = 100
+TI
interwał prosty:
[01/12/2005 00:00:00,
31/12/2005 23:59:59]
+TI
interwał złożony: every day in
january 2005 between 18:00:00
and 22:00:00
Ov erlap :
Ov erlappingInterv al
January2006 :
SingleTimeInterv al
December2005 :
SingleTimeInterv al
+E
sygnalizowane prze
aplikację, gdy
użytkownik uruchomi
promocję
akcja wysyła SMS
używając aplikacji
SMSSender
pl
s.
sygnalizacja nastapi
gdy klient nie
wykorzystał promocji w
grudniu 2005
SELECT sum (total) FROM
payment_details WHERE
payment_date between NOW
and NOW - MONTHS(3)
przekracza wartość 1000
MinutesCounterIncrement
:ValueChangedEv ent
sygnalizowane przy
każdej zmianie
wartości atrybutu
obiektu
Hours18-22 :
CyclicInterv al
interval cykliczny:
EVERY_DAY between
18:00:00 and 22:00:00
Rys. 2. Diagram obiektów UML przedstawiający dekompozycję jednej z reguł ECA
32
w
Kontrola środowiska aplikacji odbywa się przez uruchamianie operacji zewnętrznych
aplikacji. W szczególności działania jednej aplikacji mogą generować w ADBMS takie
zdarzenia, które spowodują wykonanie pewnych operacji z użyciem innej aplikacji. Na
rysunku 3 znajduje się diagram sekwencji UML pokazujący sposób, w jaki ADBMS może
kontrolować działania jednej aplikacji w reakcji na zdarzenia pochodzące z innej aplikacji.
Jest to realizacja scenariusza, w którym wyzwolona została reguła kontrolująca pracę
aplikacji SMSSender. Można zauważyć, że dopiero drugie doliczenie minuty wyzwoliło
regułę, oznacza to, że pierwsza doliczona minuta albo była 99 minutą wykorzystaną
pomiędzy 18:00 a 22:00 w styczniu 2005 r. albo została naliczona jeszcze przed godziną
18:00. Drugie zdarzenie naliczenia minuty wyzwoliło regułę i natychmiast został obliczony
warunek. Warunek okazał się spełniony i wykonana została w sposób asynchroniczny akcja
polegająca na wysłaniu wiadomości SMS. Aby wykonanie akcji nie blokowało działania
reszty systemu, należy ustalić tryb sprzężenia transakcji na rozłączny.
w
sd ADBMS Controller
CallManager
AccountManager
Activ eJDO
BonusEv ent
BonusRule
TheeMonths
SendSms
SMSSender
User
w
startCall
countMinute
zdarzenie zwiększenia licznika impulsów nie
spowodowało wyzwolenia reguł przypisanych do
zdarzenia BonusEvent
incrementCounter
da
.b
Kolejne zdarzenie spowodowało
sygnalizację zdarzenia BonusEvent
matchEvent(e)
countMinute
w odpowiedzi na zdarzenie BonusEvent
aktywny system wyzwolił wszystkie reguły
zdolne do reakcji na to zdarzenie
incrementCounter
ok:= matchEvent(e)
wyzwolenie reguły BonusRule
[ok]: triggerRules
trigger
sprawdzenie, czy warunek reguły jest spełniony
isTrue:= evaluate
[isTrue]: executeAction
pl
s.
Aktywny system w reakcji na zajście zdarzenia
BonusEvent (rys. 2), wysyła wiadomość SMS
poprzez komponent SMSSender
sendSms
warunek jest spełniony, więc dochodzi do
wyzwolenia akcji (asynchronicznie), która wysyła
wiadomość SMS używając do tego komponentu
SMSSender
Rys. 3. Diagram sekwencji UML przedstawiający sposób sprawowania kontroli aktywnego
systemu zarządzania bazą danych ActiveJDO nad środowiskiem aplikacji
Rysunek 4 przedstawia sytuację, w której ADBMS kontroluje aplikację będącą źródłem
zdarzeń. Jest to scenariusz wyzwolenia reguły ECA, mówiącej o przerwaniu rozmowy
w razie wykrycia nieuregulowanego rachunku. W tym wypadku akcja wykonywana jest
jako operacja blokująca, po to, aby niemożliwe było zgłaszanie nowych zdarzeń, które
mogłyby omyłkowo wyzwolić reguły przyznające rabaty.
Należy wspomnieć, że w niniejszym przykładzie pominięto sposób, w jaki aktywny
system zarządzania bazą danych wyznacza zdarzenia składowe do budowy zdarzeń
złożonych. Ustalenie trybu konsumpcji zdarzeń [4] ma poważne konsekwencje w sposobie
działania ADBMS.
33
R. Bar, Z. Mazur
sd Close Connection
CallManager
AccountManager
Activ eJDO
CounterIncremented
Rej ectRule
Rej ectCondition
Rej ectAction
User
startCall
countMinute
w
incrementCounter
ok:= matchEvent
[ok]: triggerRules
trigger
isTrue:= evaluate
w
[isTrue]: execute
refuseConnection
w
Scenariusz przerywania rozmowy na skutek przekroczenia zadłużenia.
W momencie naliczenia kolejnej jednostki, doszło do wyzwolenia reguły RejectRule. W rozpatrywanym scenariuszu sprawdził się
warunek RejectCondition, który określa czy został przekroczony limit zadłużenia. Następnie zostaje wyzwolna akcja, która
natychmiast przerywa połączenie.
da
.b
Rys. 4. Diagram sekwencji UML ukazujący kontrolę aplikacji będącej jednocześnie
źródłem zdarzeń
4 Podsumowanie
pl
s.
Przedstawienie klasyfikacji ADBMS miało na celu ukazanie ich szerokiego spektrum
zastosowań. Klasa ADBMS zależy od roli, do jakiej aktywny system zarządzania bazą
danych został przeznaczony i od możliwego stopnia integracji ze środowiskiem aplikacji.
Do najprostszej klasy ADBMS będą należeć systemy zdolne do wykrywania wyłącznie
zdarzeń prostych. Można traktować je raczej jako alternatywę dla tradycyjnych DBMS, niż
zupełnie nową jakość. Pozostałe klasy ADBMS są obciążone odpowiedzialnością za
kontrolowanie działania aplikacji. Kontrola taka wymaga dostarczenia przez ADBMS
zaawansowanych typów zdarzeń oraz dodatkowych modyfikatorów, takich jak tryby
sprzężenia transakcji, tryby konsumpcji zdarzeń, interwały czasowe czy maskowanie
zdarzeń, co zostało opisane w podrozdziale trzecim. Na koniec należy wspomnieć jeszcze o
dwóch niezwykle ważnych kwestiach. Pierwszą z nich jest pominięty w tej pracy aspekt
rozwiązywania konfliktów podczas wyzwalania kilku reguł jednocześnie. Do takiej sytuacji
może dojść, kiedy wiele reguł ECA współdzieli tę samą definicję zdarzenia E. Kolejnym
ciekawym zagadnieniem, którego rozwiązanie stanowi duże wyzwanie jest problem
zapętlania się mechanizmu wyzwalania reguł, do którego dochodzi, jeśli działanie akcji
powoduje kaskadowe wyzwalanie reguł tworząc cykl.
Literatura
1.
Bar R., Mazur Z.: Reguły ECA jako nośnik aktywnego zachowania w wybranej dziedzinie.
W ramach pracy zbiorowej pod redakcją A. Kwietnia: Systemy czasu rzeczywistego. Kierunki
badań i rozwoju. Wydawnictwa Komunikacji i Łączności 2005.
34
2.
3.
4.
5.
w
Bar R., Mazur Z.: Aktywna warstwa trwałości JDO jako element systemu czasu rzeczywistego.
W ramach pracy zbiorowej pod redakcją A. Kwietnia: Systemy czasu rzeczywistego. Kierunki
badań i rozwoju. Wydawnictwa Komunikacji i Łączności 2005.
Cheesman J., Daniels J.: UML Components. A Simple Process for Specifying Component-Based
Software. Addison Wesley 2001.
Dittrich K. R., Gatziu S., Geppert A.: The Active Management System Manifesto: A Rulebase of
ADBMS Features. Computer Science. Springer 1995.
Dittrich K.R., Fritschi H., Gatziu S., Vaduva A.: Samos in hindsight: Experiences in building an
active object-oriented dbms. University of Zurich 2000.
Hyesun Lee: Support for temporal event in Sentiel: design, implementation and preprocessing.
Master Thesis. University of Florida 1996.
Philippe A., Marc D., Philippe R.: Using active database mechanisms to build cooperative
applications. Journal of Integrated Design and Process Science, vol. 3, no. 1, 1999.
6.
7.
da
.b
w
w
pl
s.
35
w
da
.b
w
w
pl
s.

pobierz plik referatu

Transkrypt

Podobne dokumenty