Burmajam,
I'm not too familiar with CSLA myself yet. But if there are any concerns, or if there are any new feature requests for the Rule Manager, please let us know.
Does CSLA have it's own rules engine? And if so, can it import the rule definitions from an XML file?
We have designed a pluggable adapter interface that can support multiple import and export formats. It is relatively easy for us to provide such an adapter. Currently we have adapters for Microsoft BizTalk as well as for Windows Workflow Foundation.
Alternatively you could use the light weight rules engine component. This supports the backward and forward chaining algorithm. All the components are 100% managed C# code.
Regards,
Support
at acumenbusiness.com
Hi,
Regarding your question about CSLA built-in rule engine. It does not have engine, but CSLA framework does have handling validation rules in it. Rules for every CSLA based class are held and handled within itself. The way how you will populate rule collection is up to you. Most of us hard code validation rules, but you can also have them fetched from DB or any other source (xml or anything else), still there's no automated way to import or export rule definitions although you can always self code it.
I hope you have brief picture about validation concept in CSLA but I would also highly recommend reading this article for introduction.
Regards,
I haven't looked at Rule Manager, so the following comments are very general.
Most rule engines exist outside an object and run against the object's properties. They assume that the object has public read-write properties, so the rules can alter anything they desire.
CSLA objects encapsulate behavior, and so they often (usually) have read-only properties, and enforce at least some (preferably all) rules within the context of the object or object model.
The two concepts tend to conflict. A rule engine trying to set a property on a self-aware business object might get confused when the business object refuses (for various reasons) to allow the property to change. Or even if the property is changed, the object may go into an invalid state, because rules in the engine conflict with rules in the object.
All that said, it does seem possible that a rule engine could exist that could be invoked from a CSLA rule method to trigger running of rules against a specific property. The trick is to get the rule engine to act as an external function, so it doesn't try to alter the object, but rather returns a true or false (and preferably human-readable descriptions of any failures) to the caller to indicate whether the rules succeeded or not.
In other words, what's needed is a rule engine that can live within the constraints of encapsulation.
Rocky, All,
An interesting developing thread...
I've worked for various rules engine providers, and know that most of them are actually working as a self contained module. (So they are not actually querying business objects directly).
The reason for this is that an inference engine has to build up a dynamic rule network, and an inference engine has a notion of something being unknown. Unknown is not the same as a null value.
Unknown has a meaning that the inference engine was not able to derive a value for a particular attribute. Null means that a rule action statement did set a particular value to null, and further rule processing may or may not occur (depending on a backward chaining or forward chaining process).
Although a rule engine can set attribute values from external sources (.net assemblies, web service calls, etc), the value is copied over to it's internal model and the desired goal can be resolved. In a forward chaining framework this avoids multiple sets on the business model.
By keeping a rule engine as a self contained intelligent module, you create an architecture where Business Users (the none programmers) can maintain their business rules. A wide range of business policy changes can be made without the need for IT developers to modify the underlying business object. E.g. that a FICO score must be more than 650 .... and it's changed to ... FICO score must be more than 680 , does not need modifications on your business model. I did scan through the rule validation document mentioned above. I'm sure there are some valid business cases for that, however for none programmers this would be too technical. By externalizing business rules to the business user, you also shift the quality assurance of a business policy to the business user as well. So no finger pointing of business rules that gets lost in translation...
It is indeed correct that Acumen's Rule Manager is not free. A small nominal fee is charged for the Business editor environment. This environment comes with rule verification, rule validation and a cause-effect interactive viewer to assist the end user in building logically correct rule policies.
The rule model can be exported to Windows Workflow Foundation. This new framework from Microsoft has a free runtime rule engine (forward chaining). Integration WWF into the Enterprise business model is a responsibility of the IT architect / developer.
The rule model can also be exported as a self contained assembly that can be invoked from C#. Especially a goal driven invocation is very efficient in rule performances and addressed most of the business usage.
But hey, these are just my biased views ;-)
To be clear Sentient, my comments weren't a criticism of rules engines as being bad. Rather, there's a contrast between the use of behavioral domain objects (business objects) and rules engines that run against passive entity objects.
Each technique has its strengths and weaknesses.
As you note, a strength of the rule engine scheme is that BAs and other non-programmers can apply and alter rules. Good rules engines can also be very efficient in processing large batches of data.
On the other hand, they are quite bad as a tool for creating interactive systems. The concepts and design assumptions they make don't lend themselves to interactivity, and so they are quite poor when used with Windows Forms or WPF.
Business objects, conversely, can be very good for interactivity, and provide a rich tool for the creation of interactive interfaces. They also provide a highly maintainable end result because they are an implementation of the domain model - OOD is the best technique we've found thus far for modeling complex business scenarios.
However, a business object designed to support interactivity (OLTP) isn't particularly good for batch processing. Also there's a relatively high learning curve to become good at OOD. Finally, there's not currently any good rule abstraction for building business logic inside objects, and so we're stuck using 3GLs to do it - meaning non-programmers have no access.
This last point is what frustrates me. The skills and knowledge of the rules engine world could be translated to the OO world, resulting in domain driven business objects that leverage an abstract rule language/engine behind the scenes. The result would be really cool!
I've taken a tiny step in this direction with the rule method scheme in CSLA .NET 2.0+, but I don't have the deep knowledge of rule description languages necessary to achieve what could be. And I don't have the resources to write the graphical tools that would enable non-programmers to use that end result in any case...
Then again, perhaps there are ways to leverage some of the existing rule languages to create a rules engine that could live within the encapsulation boundary of a domain object. That'd be pretty cool.
The real challenge, I think, is to find someone with knowledge of the rules engine world, who understands the value of the OOD world. Such a person could perhaps form a bridge across this gap.
The latest release of the Rule Manager has a free adapter to import public types and their properties into the vocabulary. This should allow you to import the CSLA business objects, and write rules on top of this. The rules can be exported to the RuleML format (seperate adapter, also for free). The RuleML format is the Reaction RuleML Dialect. It should be rather straightforward to translate this to the NxBRE format. The author of nxbre is considering to import the Reaction RuleML format directly.
Cheers.
Copyright (c) Marimer LLC