I have some questions regarding the overall view of what is happening where when using Drools in a service oriented environment.<br><br>This is the idea: <br>Some applications are making use of rules for some calculations. The idea is to be able to call the rule engine as a service. Meaning: passing all facts to the rule base and based on that, rules will be fired and the facts will be updated. Rules will be called a lot so scalability is important. Next to that: the conclusion part should be able to call other services, eg. to do some calculations. An ESB is available so communication could go over that bus.<br>
<br>Now: this is how I see it:<br><br>Drools Guvnor is the place where the rules are stored and managed. (war)<br>Drools Server is where the actual calculations take place. (war but... when more load must be handled, multiple instance could be deployed).<br>
The application does a SOAP call to Drools Server (passes facts and commandos) and all is ok... <br><br>Well .. now the problem starts... I don't get it :)<br>I mean: how does Drools Server talk to the rule base ? I haven't found a clear article (but probably it does exist, just didn't find it yet) where this cooperation is demonstrated.<br>
<br>Also: I read about Camel / Spring / Rest which would be the new way to call a service... So SOAP is no longer supported (or will be deprecated as of Drools v5.x ?)<br><br>An overview and / or some best practices on how to design the architecture would be welcome.<br>
<br>Btw, as I understand it now, Drools - grid will be the way to go. But that will probably will be for version > 5.2. <br>And then again, I am confused about the split between the rule 'engine' (I have been told that there is not such a thing as a big calculating engine) and the rule repository.<br>
I kind of would expect that those two could be coupled tightly together (ok, there is probably a good reason why choices are made as they are, I am way too newbie to interfere in any such discussion).<br><br>Sincerely,<br>
Dieter D'haeyere.<br>