Concept of the rules engine and EDC

Well, i don't know what they exactly mean with 'Don't consume the data from rules engine'. Does it mean just read or also change or even delete the data?

If it would be impossible to read data within the rules engine, the client would need to provide all the required data. That would be a severe limitation of the functonality of the rules engine, because the client would need to know and collect all data the decisionservice needs.

From a technical point of view : Having build several decisionservices that consume huge amounts of data, it would be insane to provide all this data in the XML-request. Reading data from a database from within the rules engine is the best option.

My 2ct.

Hi akisoto,

An interesting point of view. Thank you for sharing this.

In my experience, a BRMS is *the* place where Business meets IT. And in the Corticon case, the EDC-part is the exact meetingpoint: IT guards the datamodel, and the business defends their business entities. Business and IT need to find a consensus, in order to get optimal integration.

Indeed, from a pure Business Rules point, extending Rulesheets to a database, preparing data as decision input, or writing output data to a database with the use of a rulesheet, is not Business Rules Management. Business Rules Management is about making Business Decisions, not about what attributes should be mapped to what database-column.

To make a difference in Business Rules and more I/O like functionality, I use colourcoding of RuleFlows: Business and IT have their own code, meaning they will not interfere in Rulesheets (or Flows) created by the other department. Does this mean that Business and IT work parallel? The contrary: They work together as they are able to read and understand (and even improve) each others work (BRM vs data management), leading to more synergy and shorter lead times in projects.

Is that an advantage? To my opinion it is!

-Gertjan

Thank you Bartel. Red Hat Japan insist on this. I think it is time-consuming to get data from messy database

and transform it to Java Object or XML for consuming the BRMS.

But Red Hat guys say 'if rules engine call the database, it will be unclear the split point of the rules and data.'

It is insane, I think.

Thank you Gertjan,

It is good point of view to beat the principal. Split the rules from program is not the true

concept of the BRMS. To integrate business and IT is true concept of BRMS.

It is good point of view.

Corticon provides the flexibility to either pass the data in on the call to the decision service or to have the decision service retrieve data; or a mix of both. What you choose depends on your needs.

In the majority of Corticon deployments, the data is passed in. This simplifies the architecture because you don't need to account for Corticon connecting to external data sources. This is especially true when you have legacy systems which cannot be easily accessed. In some cases the data  passed in can be large; for example all the data needed to process a loan application for a single applicant.

In some deployments Corticon needs to retrieve supporting data. This adds another connection to the architecture but it can be a considerable savings not passing all the data in. This is especially true where the data is selective; i.e. the rules are choosing some subset of data that is needed.  This can also be useful with reference data that you want to cache.

In still other deployments Corticon needs to retrieve the data for efficiency. An example would be a batch application where you need to process a billion records at the end of the month. In such cases efficient moving of data is essential for performance.

Short answer, it all depends on your use case.

Jim

This is an interesting question raised. The answers already provided are good, but I want to offer another explanation why JBOSS BRMS is wrong. It is impossible to separate rules from data, because the rules need data to operate. So for a BRMS to work, both data and rules should be present, else no answer can be provided. Therefore I call data and rules the business rules ecosystem.

The next question is whether or not the caller of the business rule should provide all data necessary for the business rules ecosystem to work. In my opinion it shouldn't. The caller want to know the answer to a specific business question for a specific business instance. All information to identify that business instance should be provided by the caller.

However, for reasons of information hiding, abstracting and obscuring it is not necessary for the caller to know on basis of what additional information the business rules come to a conclusion for a specific business instance. That is information that only should be known by the business rules ecosystem.

Thus, when we call the business rules ecosystem a BRMS, which enterprise architectures tend to do, adding/accessing additional data is a normal activity for BRMS. Whether EDC is the best way to do this, is another discussion ;-)

Thank you Jim,

Yes that depends on the requirement. But some customer are cheated by Red Hat even though

the system engineer in the system integrator.

Thanks mjoosen,

That sounds reasonable.