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.