Dynamic Business Rules - Where to place
Hi,
I am doing POC for a fortune 10 client and they have some business rules before crud actions are going to take place in DB. We have very minimal tables (less than 10) and its small application but web service (btw, this has to be webservice app) consumers are around 200 per sec.
The requirement with respect to business rules are also minimal (like 30 rules for entire project) but these rules will change very often(like once in a month). Assume these rules are on the enterprise level and not on the application level.
I am looking for best possible solution to achieve by developing small rules engine or putting them into another xml and apply transformation once request arrives.
I am confused of deciding which is better like putting business rules in xslt vs java business object. XSLT is allowing me to change rules with minimum impact on the system but it is hard to maintain and adding new rules (we are not anticipating any more new rules within next two years).
On the other hand, If I put in Java business object then it allows lot of flexibility to inject new rules and easy to maintain with cleaner code.
So, in short my questions are below.
1. Is it good practice to put small set of business rules in xml/xslt?
2.are there any alternative business rules engines are available?
Any other suggestion related to above discussions are welcome.
Thanks.
> Hi,
> I am doing POC for a fortune 10 client and they have
> some business rules before crud actions are going to
> take place in DB. We have very minimal tables (less
> than 10) and its small application but web service
> (btw, this has to be webservice app) consumers are
> around 200 per sec.
A clustered environment, I'll assume.
> The requirement with respect to business rules are
> also minimal (like 30 rules for entire project)
That's very small indeed.
> but
> these rules will change very often(like once in a
> month). Assume these rules are on the enterprise
> level and not on the application level.
How do the rules change? Just values (e.g., "Increase the discount given to preferred customers from 10% to 15% for this month on purchases greater than $X") or the form as well?
> I am looking for best possible solution to achieve by
> developing small rules engine or putting them into
> another xml and apply transformation once request
> arrives.
I'm not sure about the answer.
I think there are at least three alternatives:
(1) XSL transformations of XML
Pros:
Easy to change by swapping out .xsl
Can be applied before getting into the service that consumes them using aspects, queue listeners, etc.
Cons:
XSL can be a pain to write, depending on the complexity.
(2) Table-driven in a database.
Pros:
Easy to change by DBAs.
Well-understood.
Cons:
Not everyone who wants to change the rules is a DBA.
(3) Rules engine
Pros:
Rete algorithm is classic.
Perfect for forward & backward chaining
Cons:
Programmers outside AI aren't familiar with Rete
Rules can be hard to maintain when the sets get large.
Moves logic outside of objects, which should be state and behavior together.
Coupling between gutted objects and rules engine makes changes hard to do.
> I am confused of deciding which is better like
> putting business rules in xslt vs java business
> object. XSLT is allowing me to change rules with
> minimum impact on the system but it is hard to
> maintain and adding new rules (we are not
> anticipating any more new rules within next two
> years).
And that's just what you anticipate. What about those you don't?
> On the other hand, If I put in Java business object
> then it allows lot of flexibility to inject new rules
> and easy to maintain with cleaner code.
Sounds like you could get away with a well-designed interface and some side-effect free Java objects here. Table or property file driven, Spring injectable - might be just what you need. I'd do that before I'd jump into a rules engine.
%
