Business logic: moving from stored procedures to BRMS. Pros and cons [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 9 years ago.

We're developing an application which implements business logic in stored procedures on an Oracle database. It has been this way for a few years. The business rules are many, diverse and get often customized for specific customers.

Currently they're somewhat intermixed with data management and data retrieving code. I've been thinking of proposing to move some of the logic in a BRMS.

My colleagues are likely to oppose that because:

1. they experienced that the current implementation based on PLSQL is considerably more efficient than one having logic implemented in the middle tier, i.e. in Java.

   Our users often do really need short response time from our software, because it also directs their operations in industrial environments.

2. our team is not big and the people most knowledgeable about business rules are also the ones that implemented the stored procedures. They're not used to work with Java and, above all, using PLSQL allows us to ignore all the cruft regarding frameworks, system integration and mapping between different tiers.

   If we're going to switch to something else other than PLSQL it has to be something that doesn't require lot of java coding and is possibly framework independent.

3. PLSQL allows to leverage the application's weight onto an expensive DBMS. Ideally we'd like an effective integration between BRMS and DBMS.

To better present my proposal I'd need some objective figures about the following issues:

1. performance penalty for moving from stored proecdures to BRMS
2. integration between DBMS and BRMS
3. abstraction offered by BRMS compared to the one offered by PSLSQL and pure java code
4. training needed to for the switch

I looked on the net and found a few references. Unfortunately most of them compare implementations being either pure Java code vs stored procedures or pure Java code vs BRMS. I couldn't find anything comparing stored procedures and BRMS, or that describe how to integrate a stored-procedures solution with a BRMS.

Many thanks.

Answer 1

1. If you select a well established engine, it is VERY likely that performance of the rules engine will be much better than performance of a system that access a database to retrieve and evaluate rules. The engine that we are using at the moment can evaluate about 2 million objects against a single complex rule in about 50 milliseconds. That's 2 million complex objects.

2. One of the features of an engine should be a UI that allows business people to create and manage their rules,not programmers. With proper engine, programmers SHOULD NOT create and manage rules, ever. You are probably looking at the open source engines (Drools, etc.) They generally miss this point. That's why you have an impression that your guys will have to learn Java in order to create business rules. That's a wrong assumption to begin with.

3. The entire point of a business rules engine is to abstract your business logic from the main code. Your database-based system does not offer the level of abstraction the normal BRE would. I don't know your system but I'm 99.9% positive on that, based on what I know about engines and "database rules systems". You need a database to store rules. That's all.

4. That depends on the engine you choose. Training is usually minimal for IT and somewhat mid-average for business.

Hope this helps.

Answer 2

Oracle has a built-in rules engine, which is not widely publicised. However it's built with PL/SQL and of course the interface to it is PL/SQL.

I have used it for a few ETL tasks but nothing that required high performance for bulk data. If you are willing to sacrifice some performance for flexibility however I'd recommend it.

http://docs.oracle.com/cd/B19306_01/appdev.102/b14288/toc.htm