4

We have a web service that takes in input different types of messages. The function of the webservice is to merely write in a database the content of the messages. There is about one table (with foreign keys to others) for every kind of message.

We have been asked to transform the webservice in a configurable product by using a business rules engine. To have full configurability, a collegue suggested that the best way could be transform the webservice from one that accepts many types of messages to one that accepts one type of message, but in the content of the message there is a field that indicates the type of the content. This way, there would be just one table for the messages (plus other tables for static informations), and it would be more configurable using business rules engines.

What is the best way to tackle such situation?

Update: for the business rules engines we are very likely going to use an implementation of the Rete Algorithm, like Drools

gnat
  • 21,442
  • 29
  • 112
  • 288
Vitaly Olegovitch
  • 1,368
  • 12
  • 18
  • 1
    What is the rule engine actually going to be used for? "Handling messages generically" doesn't really involve much high level business logic... – Chris Pitman Aug 04 '12 at 12:57
  • @Chris well there is not much business logic now, the webservice just stores the messages and displays aggregated information about them (so maybe some Data Warehouse technology could be used). But as a future product, the possibility to introduce configurable business logic could be a plus. – Vitaly Olegovitch Aug 04 '12 at 13:21

2 Answers2

3

Integrating a business rules engine does not come for free, you do not simply plug it in and then write any business rules you want. Instead, usually each type of business rule you want to implement needs to have code written in the underlying product to support. For example, a fact has to be loaded into the engine before a rule can use it.

This is why it is useless to integrate a BRE until you have an actual use case. And that use case must include fairly complicate business rules that change frequently. In any other case, I believe you are better served by writing the logic you want in the code, and wait for the configuration use-case (with well defined expecations) to come along.

Chris Pitman
  • 3,426
  • 1
  • 18
  • 21
2

Your may problem try to code in terms of decision tree or decision table

Also, there is posts into Chris Smith's blog about decision trees:

Awesome F# - Decision Trees – Part I and Awesome F# - Decision Trees – Part II

Yusubov
  • 21,328
  • 6
  • 45
  • 71