Mam zamiar zanurzyć się w projekcie zorientowanym na reguły (używając reguł ILOGs dla .NET - teraz IBM). Przeczytałem kilka różnych perspektyw dotyczących sposobu przetwarzania reguł i interakcji z silnikiem reguł.

Dwie główne myśli, jakie widziałem, to scentralizowanie silnika reguł (we własnej farmie serwerów) i programowanie przeciwko farmie za pośrednictwem interfejsu API usług sieciowych (lub w przypadku ILOG za pośrednictwem WCF). Druga strona to uruchomienie instancji silnika reguł na każdym z serwerów aplikacji i interakcja z nim lokalnie, przy czym każda instancja ma własną kopię reguł.

Główną zaletą centralizacji jest łatwość wdrażania reguł w scentralizowanej lokalizacji. Reguły skalują się tak, jak trzeba, a nie skalują za każdym razem, gdy rozwijasz konfigurację serwera aplikacji. Zmniejsza to ilość odpadów z perspektywy zakupionej licencji. Wadą tego ustawienia jest dodatkowy koszt wykonywania zgłoszeń serwisowych, opóźnień sieciowych itp.

Wadę / minus lokalnie działającego silnika reguł stanowi dokładne odwrotne do góry / w dół centralne konfigurowanie. Brak powolnych wywołań serwisowych (szybkie wywołania interfejsu API), brak problemów z siecią, każdy serwer aplikacji polega na nim samodzielnie. Zarządzanie wdrażaniem reguł staje się bardziej złożone. Za każdym razem, gdy dodasz węzeł do chmury aplikacji, będziesz potrzebował więcej licencji na silniki reguł.

Czytając białe księgi, widzę, że Amazon uruchamia mechanizm reguł na konfigurację serwera aplikacji. Wydaje się, że wykonują one powolne wdrażanie reguł i uznają, że opóźnienie w publikowaniu reguł jest „dopuszczalne”, nawet jeśli logika biznesowa jest poza synchronizacją przez określony czas.

Pytanie: Na podstawie swoich doświadczeń, jaki jest najlepszy sposób, aby rozpocząć integrację reguł z aplikacją internetową opartą na .net dla sklepu, który nie spędził jeszcze wiele czasu pracując w świecie opartym na regułach?