Język reguł kinetycznych

Nie mylić z KRL (język programowania) .
Język reguł kinetycznych
Paradygmat Język reguł działania warunku zdarzenia
Zaprojektowany przez Phillipa J. Windleya
Deweloper Kynetx, Inc
Po raz pierwszy pojawiły się 2007
Dyscyplina pisania dynamiczny , słaby
Licencja GPLv2
Strona internetowa Dokumentacja KRL
Główne wdrożenia
KRL
Pod wpływem
JavaScript , Perl

Kinetic Rule Language (KRL) to oparty na regułach język programowania do tworzenia aplikacji w Live Web. Programy KRL lub zestawy reguł obejmują szereg reguł, które reagują na określone zdarzenia. KRL jest promowany jako język do budowania osobistych chmur .

KRL jest częścią projektu open-source o nazwie KRE, dla Kinetic Rules Engine, opracowanego przez Kynetx, Inc.

Historia

KRL został zaprojektowany przez Phila Windleya z Kynetx, począwszy od 2007 roku. Od tego czasu rozwój języka rozszerzył się o biblioteki i moduły dla różnych usług internetowych, w tym Twittera , Facebooka i Twilio .

Filozofia i projektowanie

KRL jest oparty na zdarzeniach ze ścisłą oceną , pojedynczym przypisaniem i dynamicznym typowaniem . W programowaniu sterowanym zdarzeniami zdarzenia, czyli powiadomienie o tym, że coś się wydarzyło, kontrolują przepływ wykonania. KRL wspiera model programowania oparty na trzech kluczowych ideach:

Orientacja jednostki — model programowania KRL ma podstawową cechę tożsamości. Programy KRL wykonują w imieniu konkretnego podmiotu. Idea bytu jest wbudowana w podstawową semantykę języka. Orientacja encji KRL jest obsługiwana przez bazowy KRE (Kynetx Rules Engine), więc może być używana przez każdy program działający w silniku — nawet taki, który nie jest napisany w KRL. Następne dwie funkcje ilustrują, dlaczego tożsamość jest kluczowa dla modelu programowania.

Orientacja na jednostkę wymaga, aby środowiska wykonawcze KRL wspierały pojęcie jednostki. Zestawy reguł są instalowane dla każdej jednostki.

Wiązanie zdarzeń – reguły w KRL wiążą wzorce zdarzeń z akcjami. Wzorce zdarzeń są określane przy użyciu wyrażeń zdarzeń. Zarówno zdarzenia, jak i działania są rozszerzalne, dzięki czemu programiści mogą swobodnie definiować zdarzenia i działania, które są istotne dla ich przestrzeni problemowej.

Wydarzenia rzadko są adresowane do określonego zestawu reguł. Zdarzenia są raczej zgłaszane w imieniu określonej jednostki, a zatem każda reguła wybrana z zainstalowanych zestawów reguł jednostki jest uruchamiana w imieniu tej samej jednostki. Ta koncepcja nazywa się „salience”. Zdarzenie jest istotne dla danej jednostki, jeśli ta jednostka ma zainstalowaną regułę, która nasłuchuje tego zdarzenia.

Pojedyncze zdarzenie może uruchamiać reguły z wielu zestawów reguł w środowisku wykonawczym jednostki. To, które reguły zostaną wybrane i uruchomione, zależy od zainstalowanych zestawów reguł.

Trwałe wartości danych – KRL ma klasę zmiennych zwanych „trwałymi zmiennymi” lub po prostu „trwałymi”. Istnieją dwa rodzaje trwałych: zmienne aplikacji i zmienne encji. Oba są zamknięte w zestawie reguł, w którym się znajdują, co oznacza, że ​​są widoczne tylko dla kodu wykonywanego w ramach zestawu reguł. Zmienne aplikacji są przechowywane dla zestawu reguł i są dostępne dla dowolnej jednostki wykonującej zestaw reguł. Wartości zmiennych encji są widoczne tylko dla encji, dla której zostały zapisane. Zmienne aplikacji są z grubsza analogiczne do zmiennych klas . Zmienne jednostki są jak zmienne instancji .

W szczególności zmienne jednostki są bardzo potężną koncepcją, ponieważ zapewniają programistom KRL możliwość przechowywania trwałych wartości bez bólu głowy związanego z konfigurowaniem, łączeniem i używaniem bazy danych do większości rzeczy. Ponieważ zestaw reguł reprezentuje zamknięcie nad swoimi zmiennymi encji, każdy zestaw reguł potencjalnie reprezentuje trwały obiekt danych.

Zdarzenie-warunek-akcja

KRL jest nazywany działaniem warunku zdarzenia lub językiem reguł ECA ze względu na role, jakie odgrywają te trzy podstawowe części reguły:

  • Zdarzenia – Zdarzenia wywołują określone zdarzenia. Wydarzenia są jak spust „pistoletu” – reguły. Bez zdarzenia uruchamiającego regułę nic się nie dzieje.
  • Warunki – Warunki są podobne do bezpieczeństwa broni. Jeśli wyrażenie warunkowe nie zwróci wartości true, reguła nie zostanie uruchomiona. Tak jak broń albo strzela, albo nie strzela w zależności od bezpieczeństwa, tak samo nie ma innego zdania na temat warunków. Jeśli chcesz, aby reguła uruchamiała się w odwrotnym przypadku, możesz użyć nieuruchomionego postludium , aby wywołać inne zdarzenie, lub możesz mieć regułę z warunkiem, który sprawdza przypadek przeciwny.
  • Akcje – Akcje są jak kula wychodząca z pistoletu; są końcowym wynikiem reguły. Reguła może mieć wiele akcji.

Poza zbiorem reguł zestawy reguł KRL zawierają również sekcję meta służącą do określania informacji o zestawie reguł, sekcję wysyłania zawierającą wskazówki dotyczące istotności zdarzeń oraz sekcję globalną zawierającą globalne definicje. Każda reguła jest zgodna z podanym powyżej wzorcem dla języków reguł ECA z kilkoma istotnymi dodatkami.

Podstawowa struktura reguły KRL jest następująca:

reguła { wybierz kiedy przed { } Jeśli Następnie zwolniony { } w przeciwnym razie { } }
  • Wyrażenia zdarzeń w instrukcji select deklarują warunki, w których reguła zostanie wybrana.
  • Deklaracje w preludium reguły umożliwiają obliczenie i przechowywanie wartości do późniejszego wykorzystania w regule
  • Wyrażenia warunkowe określają, czy wybrana reguła jest uruchamiana.
  • Akcje mogą być wbudowane lub zdefiniowane przez użytkownika i określać akcję reguły
  • Instrukcje w postludium reguły ( fired...else... ) wpływają na trwałe zmienne i wywołują dalsze zdarzenia.

Generatory zdarzeń

Zdarzenia KRL są wywoływane przez inne reguły generatorów zdarzeń, zwanych potocznie „punktami końcowymi”. Zdarzenia są zwykle wywoływane przez HTTP przy użyciu modelu zgodnego z Evented API, ale KRL jest niezależne od transportu. Na przykład zdarzenia mogą być przesyłane przez e-mail, SMS, MQTT lub dowolny inny system obsługujący powiadomienia w stylu push. Ponieważ Evented API jest specjalizacją koncepcji elementu webhook , każdy system obsługujący elementy webhook może zgłaszać zdarzenia dla KRL.

KRL wykorzystuje kanały zdarzeń do identyfikacji podmiotu, dla którego zdarzenie jest zgłaszane. Jednostka może mieć dowolną liczbę kanałów zdarzeń. Kanały zdarzeń są zakodowane w adresie URL dla zdarzeń przesyłanych przez HTTP.

Punkt końcowy, który generuje zdarzenie, może bezpośrednio obserwować pewną aktywność i zgłaszać istotne zmiany stanu lub może po prostu zgłaszać lub przekształcać dane zdarzenia z innego źródła (np. haka internetowego).

Punkty końcowe są odpowiedzialne za

  • zgłaszanie odpowiednich zdarzeń do procesora zdarzeń,
  • odpowiadanie na dyrektywy z procesora zdarzeń i
  • utrzymywanie stanu w celu łączenia oddzielnych interakcji z procesorem zdarzeń w sensowny sposób w celu stworzenia kontekstu.

Zasady i wykonywanie reguł

KRL jest deterministycznym językiem reguł. Oznacza to, że programy KRL składają się z zestawu reguł, które wykonują akcję po uruchomieniu. Tak jak funkcyjne , obiektowe i imperatywne są różne, języki regułowe również wymagają innego sposobu myślenia. W związku z tym pisanie zestawu reguł KRL nie jest tradycyjnym zadaniem programistycznym.

Najprościej rzecz ujmując, reguła jest działaniem warunkowym. Akcja może być dowolna, odpowiednia dla domeny. W przypadku rozszerzania stron internetowych akcje są modyfikatorami stron. W innych domenach akcja może być taka, jaka może zostać wykorzystana przez punkt końcowy. Kiedy zostaje wykonana akcja reguły, mówimy, że reguła została „uwolniona”. Zauważ, że akcja jest warunkowa: akcja jest podejmowana tylko wtedy, gdy reguła jest wybrana, a jej przesłanka jest prawdziwa.

W pierwszym etapie reguła jest wybierana lub nie, na podstawie wzorca zdarzenia w wyrażeniu zdarzenia. Wyrażenie zdarzenia reguły następuje po słowie select w regule. Na przykład w domenie internetowej najczęściej składa się to z wyrażenia regularnego pasującego do adresu URL rozszerzanej strony. Dlatego w pierwszym etapie reguła jest wybierana tylko dla określonych stron internetowych.

Drugim etapem warunkowego odpalenia reguły jest testowanie jej przesłanki, która składa się z predykatu, który służy do testowania kontekstu, w którym reguła jest oceniana. To sprawdzenie jest wykonywane po sekcji preludium reguły, w której deklarowane są wartości, dzięki czemu ma korzyść z obliczeń potrzebnych do stworzenia lub manipulowania kontekstem. Predykat trybu warunkowego jest opcjonalny, więc możliwe jest napisanie reguły, która zawsze uruchamia się, ponieważ jej selektor zawsze wybiera. Jednak najciekawsze zestawy reguł będą zawierać reguły, które uruchamiają się tylko w określonych okolicznościach.

Poniższy przykład pokazuje prostą regułę KRL:

rule good_morning { wybierz, kiedy adres URL odsłony #example.com# if morning() then notify("Witamy!", "Dzień dobry!") }

Ta reguła wysyłałaby powiadomienie „dzień dobry” do odwiedzających dowolną stronę w archiwach witryny internetowej (oznaczoną ścieżką adresu URL), jeśli w miejscu, w którym znajduje się użytkownik, jest poranek.

Zdarzenia i systemy zdarzeniowe

Zdarzenia to powiadomienie o wykrywalnym stanie w systemie komputerowym. Wykrywalny stan będzie zazwyczaj postrzegany jako zmiana stanu.

Oto trzy wymagane elementy wykrywania i powiadamiania o zdarzeniach:

  • Zmiana stanu
  • Proces zauważa zmianę stanu
  • Proces wysyła powiadomienie o zmianie stanu

Powiadomienia to transfery danych, a nie transfery kontroli wykonania. Jest to jedna z cech charakterystycznych systemów zdarzeniowych, która odróżnia je od innych typów systemów. Systemy w stylu przesłuchania wykorzystują tryb interakcji prośba-odpowiedź: „Zrobisz to?” Systemy w stylu rozkazującym wykorzystują tryb interakcji RPC : „Zrób to!” Natomiast interakcje zdarzeń są deklaratywne, stwierdzając jedynie, że nastąpiła określona zmiana stanu: „To się stało”.

Ponieważ są deklaratywne, powiadomienia o zdarzeniach narzucają semantykę znaczenia zdarzenia na procesor, a nie na generator. Generator zdarzeń nie wie, jak dany procesor zinterpretuje zdarzenie. Co więcej, nie jest nawet wymagane, aby procesor zdarzeń podejmował jakiekolwiek działania. Każdy procesor może dowolnie interpretować zdarzenie niezależnie od innych procesorów i generatorów w systemie zgodnie z jego kontekstem i określonym celem.

Generator zdarzeń „wywołuje zdarzenie”; innymi słowy, wysyła powiadomienie, że nastąpiła zmiana stanu. Procesor zdarzeń „nasłuchuje” lub „obsługuje” te zdarzenia.

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Kinetic_Rule_Language&oldid=1064635092 ”