KRÓTKO O COMPLEX EVENT PROCESSING (I CO MOŻE MIEĆ Z TEGO DEWELOPER JAVA)

Aplikacje zdarzeniowe to aplikacje, w których kod (logika biznesowa) wykonuje się w wyniku pojawienia się określonego zdarzenia. Mamy tutaj do czynienia z paradygmatem "nasłuchuj-i-odpowiedz" (ang. listen-and-respond), czyli aplikacja nasłuchuje pojawienia się określonego zdarzenia (lub komunikatu), a po pojawieniu się go, uruchamiany jest zdefiniowany kod, który przetwarza to zdarzenie (np. modyfikuje je, przekazuje do innych komponentów, wysyła na zewnątrz w postaci innego zdarzenia lub komunikatu, itp.). Na marginesie: zdarzenie jest zapisem (najczęściej w postaci cyfrowej) pewnej zmiany; komunikat jest nośnikiem, techniczną "kopertą" wewnątrz której znajduje się zdarzenie. Zdarzenie jest obiektem, może mieć atrybuty oraz metody. Przykładami zdarzenia są odczyty z sensora (np. temperatury), czy zapisy transakcji giełdowych (zdarzenie zawierałoby tutaj takie atrybuty jak symbol akcji, rodzaj wykonywanej transkacji - kupno/sprzedaż, cenę transakcji i wielkość (wolumen) operacji). Komunikaty mogą być np. w postaci komunikatów w systemie kolejkowym (JMS), rekordów zmian w bazie danych (ang. change data capture), czy mieć postać komunikatu w formacie XML lub JSON, dostarczanego do aplikacji zdarzeniowej poprzez HTTP, czy inny protokół komunikacyjny.
Aplikacje zdarzeniowe zatem: produkują (generują), nasłuchują, przetwarzają i konsumują zdarzenia.
Co jest zatem specyficznego w CEP, co zasługuje na oddzielną kategorię w przetwarzaniu zdarzeniowym ? Otóż, CEP skupia się nie tyle na przetwarzaniu pojedynczych zdarzeń, co raczej na przetwarzaniu grup zdarzeń, poszukiwaniu korelacji pomiędzy zdarzeniami w grupie, szczególnie korelacji mających charakter czasowy (strumieni zdarzeń), przyczynowo-skutkowy (czy w innym wymiarze, np. geograficznym). Zwykle, przetwarzanie tych grup zdarzeń w CEP odbywa się w czasie rzeczywistym, tzn. czas reakcji na pojawienie się określonej korelacji jest skończony (tzn. jeśli nie zareagujemy w przewidzianym czasie, to w zasadzie już nie musimy reagować wcale). Ten czas jest także często bardzo krótki (poziom mikro-, mili-sekund). Aplikacja CEP jest zatem aplikacją zdarzeniową, ale określona w niej logika wykonuje się raczej w wyniku pojawienia się pewnego zestawu zdarzeń, co więcej pomiędzy zdarzeniami w takim zestawie zachodzi zdefiniowana wcześniej korelacja.

Korelacja jest zdaniem logicznym typu "kiedy ...., to ...". Przykłady korelacji:

• kiedy pojawi się komunikat typu A, a po nim - w przeciągu maksymalnie 10 minut - pojawi się komunikat typu B, to wykonaj operację X
• kiedy pojawi się komunikat typu "Transakcja Giełdowa", którego wartość atrybutu "Cena" odbiega od średniej wartości tego atrybutu w ostatnich 30 minutach, to wykonaj operację "Kupuj"
• kiedy w ciągu 15 minut po pojawieniu się komunikatu typu A, pojawi się komunikat typu B, posiadający tą samą wartość atrybutu id co wartość atrybutu id w A oraz nie pojawi się komunikat typu C (także mający ten sam id), to ...

Korelacje mogą także obejmować wiele źródeł zdarzeń (np. wiele strumieni transakcji giełdowych).
No właśnie - typowe zastosowanie CEP, to wszelkiego rodzaju aplikacje monitorujące ("nasłuchujące") lub wyliczające w sposób dynamiczny określone wskaźniki. Przykłady aplikacji CEP w różnych branżach:

• Finanse - książkowe przykłady to aplikacje typu algorithmic trading, podejmujące decyzje biznesowe (np. "kupuję" lub "sprzedaję") na podstawie obserwacji sygnałów (danych) płynących z rynku (np. strumieni informacji giełdowych, czy walutowych). Takie aplikacje w dużym stopniu wykonują pracę maklera lub brokera, z tym, że robią to w sposób automatyczny i niezwykle szybki (np. potrafią podjąć setki takich decyzji w ciągu każdej sekundy). Takie aplikacje mogą także analizować znacznie większy zakres danych niż jest to w stanie robić człowiek. Oczywiście, programista tworzący taką aplikację, współpracując z maklerem/brokerem, zdefiniował w takiej aplikacji określone reguły - wzorce, korelacje - jakich należy wyszukiwać w strumieniach zdarzeń, którymi ta aplikacja jest zasilana. Aplikacja nie musi zresztą wykonywać samodzielnie operacji kupna/sprzedaży, a po prostu w sposób ciągły - na podstawie strumieni danych rynkowych - wyliczać, często skomplikowane, wskaźniki giełdowe, a gdy przekroczą one określone wartości (lub np. wykażą się określonymi tendencjami), to jedynie informować maklera czy brokera o zaistniałej sytuacji. Łatwo sobie wyobrazić, iż mając takiego "automatycznego asystenta", możliwe jest znacznie szerszy wgląd w sytuację na rynku i skupianie swojej uwagi głównie na sytuacjach wyjątkowych (odstępstwach od normy). Obok algorithmic trading, CEP jest często wykorzystywany w systemach wykrywania nadużyć (ang. fraud detection). Dla przykładu, możliwe jest stałe monitorowanie wszystkich transakcji bankomatowych w poszukiwaniu "podejrzanych" operacji, np. jeśli daną kartą bankomatową (czy kredytową) ktoś wykonał operację wyciągnięcia pieniędzy z bankomatu (lub zapłaty) w Warszawie, a następnie, w ciągu kilkunastu następnych minut wykonuje kolejną operację bankomatową (lub płatność), tyle, że w odległości większej niż np. 200 km od Warszawy, to taka sytuacja zasługuje co najmniej na bliższe przyjrzenie się (a może i zablokowanie karty lub powiadomienie pracowników ochrony). Kto wie, może i ta operacja okaże się prawidłowa, ale może też uda się zapobiec nadużyciu. Jak widać, mamy tutaj do czynienia z typowymi dla CEP charakterystykami:
  • duża liczba transakcji (strzelam, że w przypadku operacji bankomatowych w Polsce może to być w ciągu godziny conajmniej 100 tys. operacji - zdarzeń - do ciągłej analizy)
  • ogromna liczba reguł (korelacji) do potencjalnego wykrycia (co najmniej jedna reguła dla każdej karty bankomatowej, której użyto w ciągu określonego okresu czasu, czyli potencjalnie dziesiątki tysięcy monitorowanych korelacji)
  • użycie w analizie wielu wymiarów: czasu ("w ciągu ostatnich kilkunastu minut"), zależności przyczynowo-skutkowych ("najpierw pojawiło się zdarzenie x, potem y"), czy geograficznych ("bankomat znajdujący się w odległości większej niż 200km od Warszawy"). Często też korelacje obejmują wiele wymiarów równocześnie.
• Telekomunikacja - podobnie jak wcześniej: fraud detection, analiza ruchu sieciowego, czy możliwość generowania danych do billing'u z bardziej złożonych usług, w których finalna cena usługi jest zależna od wielu innych parametrów (zdarzeń).
• Wojsko - automatyczna analiza sytuacyjna, rekomendacje decyzji
• Logistyka i transport - do monitorowania ruchu towarów
• Przemysł - do nadzorowania linii produkcyjnych

Literatura (a także dostawcy technologii CEP ;-)) mogą wskazać znacznie więcej przykładów zastosowań. Ważne jest jednak to, że w gruncie rzeczy chodzi o to samo - możliwość przetwarzania jednego lub więcej strumieni danych, poszukiwania w nich określonych sytuacji, a gdy one zajdą - wykonywanie określonej logiki biznesowej.
Dosyć często zadawane jest pytanie, dlaczego nie użyć innych technologii do rozwiązania powyższego problemu ? Na przykład bazy danych. Takie próby były prowadzone, ale mimo pewnych sukcesów (np. wymyślenia trigger'ów), okazało się, iż SQL i technologie bazodanowe niezbyt nadają się tutaj do szerszego zastosowania. Analiza zdarzeń musi odbywać się w sposób ciągły (ang. continous queries). Analiza musi obejmować zależności czasowe i przyczynowo-skutkowe. Także wydajność i opóźnienia (ang. latency) w przetwarzaniu zdarzeń w bazach danych - "nastawionych" na transakcyjność - okazały się w praktyce nieakceptowalne. Nierzadko bowiem trzeba analizować strumień milionów zdarzeń na sekundę i w sposób ciągły wykonywać dziesiątki tysięcy korelacji, zachowując jednocześnie opóźnienia (czas przetwarzania pojedynczego komunikatu) na poziomie mikrosekund.
Nota bene: CEP nazywa się czasem "odwróconą" bazą danych. Otóż w typowych systemach DBMS, mamy do czynienia z relatywnie statycznym zbiornikiem danych na którym wykonywanych jest wiele, zmiennych zapytań ("relatywnie statycznym", gdyż rzadko mamy do czynienia z bazami danych, których np. 99% zawartości ulega zmianie w każdej sekundzie). W CEP jest odwrotnie, tzn. mamy do czynienia z relatywnie stałymi zapytaniami do których "wpychane" są zmienne strumienie danych (zdarzeń).
OK, ale cóż z tego CEPa ma deweloper Java ? Otóż, deweloperzy Java mogą budować tego rodzaju aplikacje używając technologii, które znają (i które są powszechne !):

• Java - w której opisywana jest logika biznesowa, czyli co ma być wykonane jeśli dana korelacja zdarzeń zajdzie
• SQL - gdyż do opisu korelacji między zdarzeniami możliwe jest zastosowanie języka EPL (Event Processing Language), który bazuje na SQL, tzn. rozszerza go o konstrukcje specyficzne dla złożonego przetwarzania zdarzeń, np. okna czasowe, czy wzorce przyczynowo-skutkowe.

Co więcej, dostępne są technologie middleware'owe, np. zdarzeniowych serwerów aplikacyjnych Java, które pomagają:

• deweloperom, bo oddają w ich ręce wygodny model budowy aplikacji oraz zestaw gotowych mechanizmów pozwalających uniknąć "powtórnego wymyślania koła" podczas budowy aplikacji zdarzeniowych.
• administratorom, czy osobom odpowiedzialnym za funkcjonowanie aplikacji CEP, gdyż oddają w ich ręce mechanizmy związane z wysoką dostępnością i skalowaniem rozwiązania (klastrowanie), bezpieczeństwem, czy zarządzaniem.

Dla przykładu - zdarzeniowy serwer aplikacyjny powinien zawierać procesor CEP, czyli silnik efektywnie wykonujący zdefiniowane zapytania (korelacje). Wykorzystanie do opisu korelacji języka deklaratywnego - takiego jak SQL (lub jego pochodne) - sprawia, że w bardzo dużym stopniu "zdejmuje się" z programisty pracę związaną z określeniem w jaki sposób mają być przetwarzane zdarzenia. Programista jedynie deklaruje efekt końcowy - "chcę dostać takie dane, gdy zajdzie taka sytuacja". Problem efektywnego wykonania tego zadania - czyli w jaki sposób ma być wykonane "nasłuchiwanie" pojawienia się zadeklarowanej korelacji - spada na silnik (procesor CEP). Tutaj także widać analogię do DBMS i np. SQL - w bardzo dużym stopniu programista piszący aplikację przetwarzającą dane w bazie danych nie musi interesować się tym, w jaki sposób silnik bazodanowy (i inne elementy) wykona zapytanie i dostarczy danych. Tym samym aplikacja powstaje szybciej i może zawierać bardziej złożoną logikę manipulacji danymi. Oczywiście, czasem wiedza o tym jak działa dany silnik bazodanowy jest programiście przydatna - np. aby zapewnić odpowiednio wydajne wykonywanie zapytań. Zauważmy jednak, iż optymalizacje zapytań wykonuje się (a przynajmniej powinno się wykonywać) dosyć późno w procesie budowy aplikacji (a czasem nawet całkiem późno, bo na etapie produkcyjnego jej działania) i tylko wtedy, gdy rzeczywiście wydajność jest niezadowalająca.
Warto poznać CEP i technologie wspierające tego rodzaju przetwarzanie oraz stosowane w nich języki opisu zdarzeń. Warto próbować wyobrazić sobie, na ile łatwo dałoby się zrealizować złożone przetwarzanie zdarzeń nie mając do dyspozycji tego rodzaju technologii.

Więcej o CEP przy użyciu Java: http://jdn.pl/node/1582