I have some questions regarding the overall view of what is happening where when using Drools in a service oriented environment.
This is the idea:
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.
Now: this is how I see it:
Drools Guvnor is the place where the rules are stored and managed. (war)
Drools Server is where the actual calculations take place. (war but... when more load must be handled, multiple instance could be deployed).
The application does a SOAP call to Drools Server (passes facts and commandos) and all is ok...
Well .. now the problem starts... I don't get it :)
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.
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 ?)
An overview and / or some best practices on how to design the architecture would be welcome.
Btw, as I understand it now, Drools - grid will be the way to go. But that will probably will be for version > 5.2.
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.
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).
Sincerely,
Dieter D'haeyere.