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
Web services and business rules engines
web services;configuration;rules engine
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.