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

  • 1
    What is the rule engine actually going to be used for? "Handling messages generically" doesn't really involve much high level business logic... Aug 4 '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. Aug 4 '12 at 13:21

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.


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

  • This is a good solution if you plan to implement your own business rule engine. In our case we would like to use an existing one and just configure it. Aug 4 '12 at 9:28
  • Yes, if you are planning to keep it simple then this might work very well.
    – Yusubov
    Aug 4 '12 at 9:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.