Kural motoru kullanımı bir uygulamanın tasarımını, uygulamasını ve performansını nasıl etkiler?

Ben kural motorları yeteneği ile ilgileniyorum:

• iş odaklı mantık üzerinden başlatma ve yineleme
• "işletme kullanıcıları" nı geliştiriciler yerine bu kuralların fiili olarak değiştirmesini sağlamak
• genel olarak iş kurallarını kavrar

Ayrıca, kural motoru kullanmak uygulamanın kalitesini etkiler mi?

Binlerce makine kullanan çok katmanlı, bulut tabanlı dağıtılmış bir mimariye karşı 1 makine kurulumuna dağıtıyorsanız kural motoru kullanımı değişiyor mu? Nasıl farklı olurdu?

Teknik olmayan personelin iş kurallarını değiştirmesi için bir arayüz ortaya koyup koymama kararı, büyük ölçüde projenin hedefleri, projenin maliyeti, projenin ömrü ve bilginin bilinmeyenlerin bilinmeyenlere oranı gibi çeşitli faktörlere bağlıdır. projesi.

Örneğin, hiç kimsenin kurallar arayüzünü kullanmayacağına inanırsam, büyük olasılıkla onu uygulamayı seçmezdim. Ancak, değişikliklerin sık olacağına ve farklı son kullanıcıların farklı kuralların uygulanmasını bekleyeceğine inanmam için bir nedenim olsaydı, bu tür bir işlevsellik oluşturmak için çalışmayı düşünürdüm.

Bunu bir projede yapmayı seçtim ve özelliğin yaygın olarak kullanılması yıllar sürdü. Sonunda işleri kendileri özelleştirmek isteyen son kullanıcılara sahip olacağımızdan şüphelendim, bu yüzden bu işlevselliği parçalar halinde uyguladık.

Sadece geliştiriciler veya yöneticiler gibi belirli kişilerin kullanabileceği bir şey olarak başladı. Arayüz tıknazdı, ancak ne yaptığınızı biliyorsanız kullanılabilir. Ancak ürün tamamlanmaya yaklaştığında, kural motoru arka uç mantığı işe yaradı ve tasarım ekibimiz ona güzel, müşteriye dönük bir kullanıcı arayüzü verdi.

Farklı yapsaydım, sadece öğrenme eğrisi yüksek olduğu için farklı bir veritabanı mimarisi seçebilirdim. Ancak kısacası, erken inşa edilmesi, daha sonra kodda geri dönme ve tüm dinamik kuralları içermek için yeniden düzenleme yapmak zorunda kalmadan baş ağrısı çeken birçok müşterinin karşılaştığı özelliklere yol açtı.

Bunu yapacak olsaydım, kuralları ifade etmek için bir Etki Alanına Özgü Dil yaratırdım ve belki biz türlere istenirse değiştirmek için bir kullanıcı arayüzü verebilirdim. Ardından kuralları değerlendirmek için işlevsel bir dil (Haskell, Lisp veya Erlang gibi) kullanın.

Eğer muazzam bir paralellik gerekiyorsa, eşzamanlılığı çok iyi yapan Erlang ile giderdim. Erlang kullanmak 1 düğümden 100 veya daha fazlasına ölçeklenebilir.

Bir veri kümesine uygulanacak bir Cebir olarak kuralları düşünüyorsanız, kodunuzda neyin gerekli olduğunu anlamak ve kendinize (veya yöneticilerinize) doğru olduğunu kanıtlamak çok daha kolay hale gelir. Bu, işlevsel bir dilin sizin lehinize çalışacağı yerlerden biridir.

WF (windows iş akışı temeli) tabanlı bir uygulama yazdım. Patronum (DBA) WF'nin eşzamanlılık planlamasına gerek kalmadan çoklu iş parçacığı yapabileceğine ikna oldu. Hafıza iyice bölündü, ama sadece birkaç paragrafta açıklayamadığım birçok sorun vardı ve bu sadece sorunuzla biraz ilgili ... bu yüzden devam ediyorum.

BL:
WF bunu yineleyebiliyor .
nontechies "bir uygulama oluşturmak" için izin:
mimarlık çalışır VE nontechies teknik sınırlamaları anlamak EĞER bunu iyi yapar ... Bizimki yoktu.
Genel olarak iş kurallarını kavrayabilme:
Sharepoint'in iş akışlarını otomatikleştirebileceği gibi bazı temel şeyleri yapabilen bazı eklentiler vardır. Bu eşyalara girmedim.
Yazılım gerçeklerinin kalitesi:
Vasat. WF bizim amacımız için iyi performans göstermedi, ancak sistem kötü tasarlanmış ve ellerim bağlanmıştı.
Uygulamaların hızı:
Yavaş. Öğrenme eğrisi hem geliştiriciler hem de son kullanıcılar için oldukça diktir. WF ayrılmış bellek (app-domainleri hatırlıyorum) çapraz iplik iletişim, muteksler ve diğer iş parçacığı kavramları kludgy yaptı ya da sadece herhangi bir şekilde işe yaramadı.

Sonuçta, WF'nin uygulanma biçiminde başarısız olduğunu kanıtlayan bir prototip yazdım. Bunu ortak çoklu iş parçacığı ile değiştirdim. Performans ve kod okunabilirliği arttı. İlk profesyonel WF uygulamam olduğu için bunu bir tuz tanesi ile al.

Nontech'ler, BL'nin bütün "kukla aşağısına" potansiyel olarak büyük bir negatif olmadan herhangi bir programlayıcı gerekmeksizin neredeyse her şeyin mümkün olduğuna inanabilirler; bununla ilgili sosyolojik sorunlar projeyi öldürdü.

Geri dönüp bunu yapabilecek biri varsa yoluma : kullanım geleneksel parçacığı ve BL yoluyla elde döküm Dekoratör Modeli. Bu teknolojileri kullanan bir konsept kanıtı yazdım ve işe yaradı. VE BL eşlemesi, BASİT UI'ye sarılmalıdır.
Güncelleme
Eşzamanlılık sorunları ile çalışırken yazdığım eski bir yazı buldum. Kod, paralel iş akışlarında "merhaba dünya" nın yazdırılmasının, kapakların altında neler olup bittiğini anlamadan (WF soyutlamasının tüm amacını yenen) nasıl çalışmadığını gösterir. MSDN moderatörü, paralel etkinliklerin gerçekte nasıl ardışık olduğuna dair üst düzey bir genel bakış açıklar. O temel bir şey yapmak için temelde "tüm kılavuzu okumak gerekir" ile sonuçlanır. http://social.msdn.microsoft.com/Forums/en/windowsworkflowfoundation/thread/8a1fa165-ad5c-4cd2-b489-7ea5fc31fed8

İyi şanslar.

Java kodundan Oracle kural motoruna bağlanmak için mükemmel bir deneyimden daha az yaşadım. Bunlardan bazıları kural yazarlarının deneyimsizliğinden kaynaklanıyor olabilir, ancak karşılaştığım şey bu.

• Kural motorumuzu vatansız bir cihaz olarak uyguladık. Arayanın tüm parametreleri toplaması ve değerlendirme için motora iletmesi gerekiyordu. Bu, kuralın başka bir veri alanına ihtiyacı varsa, tüm istemcilerin güncellenmesi gerektiği anlamına geliyordu, Bu, kuralları tüketicilerinden bağımsız olarak güncelleyebilme avantajını reddetti.
• Motor bir SOAP WSDL yayınladı, ancak kural kümesinden otomatik olarak oluşturuldu. Kurallardaki küçük değişiklikler tüketicilerle olan sözleşmeyi bozacaktır.
• Motor kuralları değerlendirmede iyiydi, ancak değerlendirmenin neden başarısız olduğunu bize anlatmakta korkunçtu. Bilgilendirici hata mesajlarını kullanıcıya geri göndermek zordu.
• WSDL genel tüketim için uygun değildi. En basit kural kümesinde, kural tabanının içlerini gösteren 14 sayfalık bir WSDL vardı. İş dostu bir cephe sunmak için bir SOA çeviri katmanı koymak zorunda kaldık. Bu nedenle,% 100 güvenilir bir yerel kütüphaneyi çağırmak yerine, döngüde iki ekstra sunucu vardı. Bu en azından güvenilirliği arttırmaz. Ayrıca, kural imzasında yapılan herhangi bir değişiklik, kodu güncelleyen üç farklı ekibi içeriyordu. Agile tanımım değil!
• Kural kümesi eklemeye ihtiyaç duyduğunda, WSDL'nin güncelleştirilmesi gerekir; bu da istemcilerin artık anlamadığı anlamına gelir. Bu, v2, v3 .. için güncellenen güvenlik duvarı kurallarına ihtiyaç duyulan yeni SOAP uç noktalarının eklenmesine yol açtı.
• Kurallar, basit kurallar için kolayca anlaşılabilen, ancak karmaşık kurallar için opak olan "yapılandırılmış ingilizce" olarak ifade edilmiştir.
• Dili yazan kuralları bilen müteahhitleri asla bulamadık.
• Kural dili diziler, özyineleme veya nesne yönelimi uygulamadı. Bir durumda, bir kuralın uygulanmasının tek yolu, kuralın VB'de uygulandığı bir Excel elektronik tablosuna ek bilgi koymaktır. Neden rahatsız oluyorsun?

Bir kural motoru kullanma (ya da kullanma) seçiminin açık olduğunu düşünmüyorum. Kullanmayı düşündüğünüz herhangi bir motoru prototiplemenizi ve ardından bilinçli bir karar vermenizi öneririm. Kesinlikle gümüş bir kurşun değiller ...